Re: no version magic, tainting kernel.

[Kai Germaschewski]

On Mon, 27 Jan 2003, Joel Becker wrote:

> On Mon, Jan 27, 2003 at 12:31:07PM -0600, Kai Germaschewski wrote:
> > Well, if you're doing things in your module which break with the command 
> > line options the rest of the kernel is using, I'd claim you're playing 
> > tricks in your module which you shouldn't. The only place I'm aware of 
> 
> 	I'm not so sure about that.  Some gcc things tweak us, and the
> some code has had to deal with it.  This isn't something that happens
> often, but it still can.  In addition, CFLAGS_filename.o does not allow
> removal of options, merely the addition if I am not mistaken.

Well, I suppose arguing about that without a concrete example is kinda 
pointless.

> > Basically, yes. The build process needs to be able to write, e.g. to 
> > compile its helper code in scripts/, so init/vermagic.o is just another
> > file being written.
> 
> 	If my distribution has installed /usr/src/linux-x.y, I can't
> compile against it.  Even though the 200MB of a kernel tree is already
> taking up space on my system, I have to download *another* 30MB and
> install it as *another* 200MB and build it to an eventual *another*
> 260MB of kernel tree.  So, for every kernel I want to support, I have to
> have 260MB of built tree.  And that's just for my userid.  Anyone else
> on the box has to have their own n_kernels * 260MB of space waste.

You ignored the fact that I said you will be able to use separate
src/objdir, which means you can have your source read-only.

> > fact, these checksums are generated as part of the compiled objects, so
> > recording checksums needs all other compiled objects to be around. If you 
> 
> 	But, once the checksums are recorded, the compiled objects are
> no longer needed, no?  It still remains that a kernel header package
> with associated correct autoconf.h and checksums is at least an order of
> magnitude smaller than a built kernel tree.

Yes, all you really need is the checksums. Then again, you also want a way 
to verify a way that the checksums match the ABI as determined by the 
current .config. I mean, just using the previously recorded checksums 
without verifying is kinda pointless, they'll just always match and not 
fulfill their function.

> > As I said, I am sure interested in working with people and distros to get 
> > something which everybody can live with. I'm wondering how RedHat manages 
> > to have one tree for different configurations, since in that case, at 
> > least .config/autoconf.h, EXTRAVERSION and the module version files 
> > (*.ver) need to differ, so that kinda seems not possible in one 
> > (read-only) tree.
> 
> 	Red Hat plays tricks.  They add a <rhconfig.h> to the top of
> autoconf.h and have some extra defines so that chunks of autoconf.h look
> like:
> 
> #ifdef UP_FLAG
> ... some UP CONFIG_* options
> #else
> #ifdef SMP_FLAG
> ... some SMP CONFIG_* options
> 
> and so on.
> 
> 	This does indeed track modversions as well (I don't recall which
> files do the switching).  This actually works pretty well, but it depends
> on the fact that their kernel flavours (up, smp, large ram) are known
> at the time they build this setup.  This isn't necessarily the proper
> solution for the generic kernel.  
> 	It still remains that in 2.4 you need the headers for the kernel
> plus the proper bits created by config/modversions.  You don't need
> anything else, and you don't need any writability after the initial
> generation.  This takes significantly less space than an entire built
> tree, and is usable from /usr/src as a readonly entity.  Requiring that
> *each user* have the kernels they wish to build installed and fully
> built is a step back, IMHO.

Yup, I now looked into what Redhat does. It's an obvious sign that there
is work to be done, in particular making the build system work in a way
that vendors don't need to kludge around it would definitely be nice.

I have to admit that I did not think about the needs of distro vendors
when implementing the new module version code (the other small issues I
think can be worked around easily enough), and it's definitely an area
which needs serious thinking and improvement. However, I think I need to
finish the current work first, i.e. make sure the module versions actually
work and then the separate obj / src dir stuff.

Afterwards I think it's a really good idea to come up with a way to
sensibly handle external modules, and it'd be much appreciated when all of
the affected people (i.e. distro and external module guys) would provide
input for that.

--Kai