Subject: Re: PR 31468 -- distributed LKMs are not useful because of incompatible config
To: Pavel Cahyna <firstname.lastname@example.org>
From: Chuck Silvers <email@example.com>
Date: 10/30/2005 14:55:23
On Sun, Oct 30, 2005 at 07:47:19PM +0000, David Laight wrote:
> On Sun, Oct 30, 2005 at 08:38:11PM +0100, Pavel Cahyna wrote:
> > On Sun, Oct 30, 2005 at 06:30:44PM +0000, Christos Zoulas wrote:
> > > I think that DIAGNOSTIC and DEBUG do not belong in GENERIC kernels.
> > It was also suggested to have DIAGNOSTIC in GENERIC for -current, and turn
> > it off before releases IIRC.
> How feasible would it be to make the DIAGNOSTIC and DEBUG tests boot time
> (or even sysctl changeable) options?
that would somewhat defeat the purpose of these... the idea is that production
kernels shouldn't have all the debug code slowing them down. having a zillion
run-time checks for whether we do debug checks would also slow things down,
though perhaps not as much.
> If nothing else it would reduce the number of 'standard' kernels we build!
> As well as making it easier to run a kernel with the tests enabled.
I would like to see us make better choices about run-time vs. compile-time
stuff too. being able to globally turn most debugging code off at
compile-time is good, but having a zillion compile-time options leads to
building a zillion different binaries, which isn't so good and can't
really be tested well at all. there is a better middle ground to be found.
> I also wonder how many of the build options necessarily change the code?
> If only MP did, then we'd only need to compile all the kernel files twice
> and be able to link any kernel we liked - adding or removing drivers at will.
it's worse when data structures have compile-time conditionals.
for instance, LOCKDEBUG changing the size of a lock (and thus of many other
structures) is an enormous pain. one thing I want to do soon is
to move the LOCKDEBUG data out of the lock structure into some global
or per-CPU data structure, so that structures containing locks will
stay the same regardless of whether this option is on or off. ideally
all compile-time options would similarly not affect the kernel ABI,
but some will be easier to fix than others.