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.

-Chuck