-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrey Borzenkov wrote: > [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)
<disclaimer type="kernel 2.6 newbie"> Since the binary kernel packages ship with vmlinux and binary modules, can they not be linked into the kernel-source-$flavour package, so that you need kernel-source-base and kernel-source-$flavour (which requires kernel-$flavour), thus avoiding the need to include two copies of many files? kernel-source would be a virtual provides in kernel-source-$flavour. This assumes either modpost can use compressed modules, or we ship uncompressed modules in kernel binary packages (or some similar solution). Of course, if this is what you meant, just ignore me. </disclaimer> > > 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. You don't maintain binary kernel module packages I think? If it does work, it would make life easier ... > > - 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. Option 4 looks the best long-term solution (and useful to others too). Regards, Buchan - -- |--------------Another happy Mandrake Club member--------------| Buchan Milne Mechanical Engineer, Network Manager Cellphone * Work +27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/qPnGrJK6UGDSBKcRAmf8AJ9vJrOikXoWTR3RW1waw4fV/kwxJwCeJUR/ ADYAZq40cv0KBEFt74+BByU= =upMp -----END PGP SIGNATURE-----
