Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 27 Jan 2003 17:59:40 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 27 Jan 2003 17:59:40 -0500 Received: from chaos.physics.uiowa.edu ([128.255.34.189]:207 "EHLO chaos.physics.uiowa.edu") by vger.kernel.org with ESMTP id ; Mon, 27 Jan 2003 17:59:38 -0500 Date: Mon, 27 Jan 2003 17:08:50 -0600 (CST) From: Kai Germaschewski X-X-Sender: kai@chaos.physics.uiowa.edu To: Joel Becker cc: Christian Zander , Mark Fasheh , Thomas Schlichter , "Randy.Dunlap" , Sam Ravnborg , LKML , Rusty Russell Subject: Re: no version magic, tainting kernel. In-Reply-To: <20030127221523.GP20972@ca-server1.us.oracle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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 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/