[lkml]   [2003]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: no version magic, tainting kernel.
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

> > 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:32    [W:0.105 / U:2.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site