[please Cc me on this thread. thank you]
-----Original Message----- > > On Tue, 04 Nov 2003 17:21:12 +0300 > "Andrey Borzenkov" <[EMAIL PROTECTED]> wrote: > > > I fails to see these directions on www.minion.de. Quoting README: > [ snip ] > > anyway - it works. It works for may people. Actually so far it worked > > for everyone :) > > Actually, no, there were some problems with the new kbuild : ok, I apologize, I meant "with custom built kernel" :( > http://www.ussg.iu.edu/hypermail/linux/kernel/0307.1/1162.html > http://www.mail-archive.com/[EMAIL PROTECTED]/msg114289.html > > I could add all this stuff in the %post of kernel-source, what do > you think of it ? no enough see below > But that would require the correct kernel to be installed before > kernel-source, because we need the correct > /boot/config-%name-%version-%release to make oldconfig. > What to do if both normal an -smp kernels are installed ? > To summarize so far. On 2.4 module versions have been appended to symbol names themselves and stored in modversions.h file. It allows using sources without object modules to built external off-tree modules and using some #ifdef magic evem prepare single source tree that can be used to automatically build external modules for currently running kernel. On 2.6 module versions are stored in object file. As last step kbuild executes modpost that extracts versions (CRCs) from objects that define them and stores them in objects that use them. I.e. if module mod1.o defines mod1_foo that is called by mod2.o, the CRC(mod1_foo) is extracted from mod1.o and stored in mod2.o *object*. Later on this is used by kernel module loader to check that module matches kernel for which it was built. This step as implemented currently in kbuild needs *all* modules and vmlinux for build tree. It is called as modpopst vmlinux mod1 mod2 .... - enable verbose and see :( Which means that to be able to buid external modules kernel build tree must contain vmlinux and *all* module objects :((( Which also means that if we want to build for several kernel flavours we need vmlinux and modules for *every* kernel flavour :((((( So what can be done so far. 1. Disable modversions. I have not tested it as yet but I presume that as this problem exists only in presence of modversions it should allow you to build modules. IIRC in this case kernel version is still stored so it should not allow you to load smp module for up kernel. needs checking. 2. Ship separate kernel-source-up etc for every kernel flavour that contains vmlinux and kernel objects. Use the same kheader trick to link /usr/src/linux to currently booted kernel sources. This means quite a bit of space OTOH most users have just one kernel installed ... apparently this is approach taken by RH (see quoted thread and recent Arjan reply). 3. Use separate build tree approach and ship single kernel sources that point to different kernel build trees that are distributed as separate packages. (link established by kheader) That saves us overhead of having sources n x times. It almost certainly requires Makefile fiddling but not very large. It may fail for some non-conformant Makefiles (but then anything can fail) 4. Teach modpost to extract module versions from /boot/vmlinuz and /lib/modules. Any takers? :) So far two most attractive approaches are - disable modversions. Frankly speaking, it was meant to allow people to reuse modules across different kernel versions - as it stands now I have never seen that module from one release could be loaded on another. It seems to be more trouble than it is worth. - take approach 3. We need to teach users how to use 2.6 kbuild anyway, there is quite a bit of jump, so we may teach them how to use separate build tree at the same time. -andrey
