We’ve gotten a couple of really good questions about our Linux* drivers so I figured I would share them and the answers. 

 

1. I have found the following CFLAGS for x86_64 architecture in the Makefile of the driver.

 

-mcmode=kernel -mno-red-zone

 

Are these options mandatory for 64 bit architectures, or can I remove them when I directly use the kernel build system (copy the sources to drivers/net/igb)?

 

This article from the GCC site explains them both in Linux terms.  But I'll try to put them into English   The kernel mode tells the compiler to build it for inclusion in the kernel, so you do need that one.  The no red zone one will build the driver without using the red zone, which is a scratch pad of sorts near the stack in memory.  They are turning this off so that if somebody else is using the scratch pad that the driver won't try to.  Again, I would leave this one alone.  The driver isn't designed to use the scratch pad, but you never know when the compiler would decide to mess with it.

 

Both these options are only *used by* our Makefile when building for the 2.4 kernel.  The 2.6 kernel already contains these flags, and uses a system called KBuild that we hook into to build the out of tree drivers just like any other kernel module.  Basically all the Makefile ends up doing is

 

make –C /path/to/linux/source M=/full/path/to/driver CF=$(CFLAGS_EXTRA)

 

and the driver is automagically built.

 

 

2. The README says that Intel supports the driver only as a loadable module. Does this mean that we do not get support when we statically link the driver or does this mean we are not allowed to link it to the kernel?

 

As for the readme, I think that is describing the difference between having the source configured for being in a distribution vs a standalone driver.  The tarball is in "stand-alone" mode and would need some modification to be built into the kernel like if it was a stock kernel driver.  If you remember this blog entry it has some details on that.

You can use make install with the driver and that will have it be loaded when the O/S starts, but if they want to build it into the kernel they need to be careful.  The article shows some tips on how to do it.  They can also look at kernel.org for our driver and they can see what it looks like when in the kernel.  The readme is just warning that the driver tarball isn't designed for inclusion into the kernel and if you do so there maybe troubles.  But I think there are enough researchable materials for you to do it.  (kernel.org, my blog page).

 

One other option is to build the driver as a module and include it in the initrd by using some of the extra options to mkinitrd to force the driver to be included.  This has the added benefit of not requiring “coding” to get the driver dropped into the kernel directory structure.

 

Big ending!

1)    You can reply to this blog posting if you have a question for us to answer next time

2)    Thanks for using wired Intel® Ethernet!