On Sun, 2004-03-07 at 17:08, Arjan van de Ven wrote: > On Sun, Mar 07, 2004 at 05:05:27PM +0100, Sam Ravnborg wrote: > > On Sun, Mar 07, 2004 at 03:01:31PM +0100, Arjan van de Ven wrote: > > > > and it's missing the symbols from > > > > module files. > > > > > > sure but the module files are generally installed... > > I'm aiming for a situation where I can build external modules, > > using an almost clean kernel src tree. > > Personally I don't see the point. I'm perfectly happy with the current > situation with the exception of not using System.map and co. > > From a distribution kernel pov; I already ship a subset of files for building > modules against (basically include/, the KConfig and makefiles), which only > not 100% works because I don't ship vmlinux.
We have tried that with our latest round of kernels (still 2.4), and the results have been mixed. You need various headers outside include/ for some obscure external modules. Amazingly there are even external modules that make use of kernel C files. All in all, in the end I changed my mind. I now think that it's better to build modules against a clean kernel source tree that additionally has the modversions file copied in. This already works when using O=. With the SUBDIRS= approach, the kernel source tree must include a few compiled files (scripts/ stuff), and it cannot be read-only. I'm still undecided whether it makes sense to disallow the SUBDIRS= approach completely and only allow building with O=. (Note that this doesn't change the modversion dump file argument.) When building with SUBDIRS=, you ideally want a (read-only) kernel source tree that can adapt to different configurations (e.g., by doing like this: make -C $KERNEL_SOURCE modules SUBDIRS=$PWD FLAVOR=bigsmp ), the default being the running kernel. The RedHat kernel has had a partial solution for merging autoconf.h. I have patches that implement a more complete solution that I'd happily send them to an appropriate place for discussion, but I don't think this would make much sense in mainline. Particularly because, while O= building has a slightly higher overhead, it gets rid of those problems, anyway. Cheers, -- Andreas Gruenbacher <[EMAIL PROTECTED]> SUSE Labs, SUSE LINUX AG ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
