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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 31 2003 - 22:00:17 EST