AFAICT this method (adding independent modules to the kernel Makefile
tree) is the only way to guarantee that the module is compiled with the
correct options. I have seen people try to copy kernel compile options
by hand into a separate source tree and get them wrong, in particular
they get genksyms wrong most of the time. Also most separate compiles
completely omit dependency checking. Using the kernel makefile
structure gets it right every time.
It can be done without copying files into the kernel makefile, though.
See my paper at last year's Usenix conference (on the Freenix track) for
an extended treatment about how to do things right in an independent
way. Also, take a look at the stand-alone serial driver distribution
(http://web.mit.edu/tytso/www/linux/serial) for an example of how to do
this right. This is a driver that will work correctly on Linux 2.0,
2.1, 2.2, and 2.3 kernels, with the makefile doing automatic
configurations so the serial driver even properly *export* modversioned
symbols that can be used by other stand-alone kernel packages (such as
pcmcia drivers).
Sure, you have to make adjustments for different as newer kernel
versions come out, but the same is true (if perhaps doubly true) for
distributing kernel patches. I've also distributed with the serial
driver a shell script which installs the serial driver into a kernel
tree (for folks who want to do that for one reason or another), but
figuring out which PCI id's have to be inserted into linux/pci.h is
tricky, and change from kernel version to version; a simple patch would
never do it, and I haven't had the time to write the perl script that
would examine pci.h and figure which defines have to be added to pci.h
and which don't need to be added.
At some level, doing things stand-alone is actually easier from a
maintenance point of view, once you have the basic infrastructure in
place.
I invite people to take a look at the infrastructure found in the
stand-alone serial package, and to use it for their own drivers. If you
can think of improvements to it, please suggest them to me. If you'd
like some help in adapting the stand-alone driver infrastructure for
your own driver, let me know, and I'll try to give you some pointers.
I really belive that being able to do source distributions that are
decoupled from the kernel release cycle is a valuable thing --- look at
how well the PCMCIA distribution has worked. Even now that some of the
PCMCIA drivers are getting folded into the kernel, the fact that you can
get the latest PCMCIA drivers (which get released for more frequently
than 2.2 kernel patches) and use them against a 2.2 or even 2.0 kernel
system is a Very Good Thing.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/