Re: add DIAGNOSTIC back to GENERIC/INSTALL

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Thu, Jun 16, 2011 at 04:20:06PM +0100, Mindaugas Rasiukevicius wrote:
> I have few concerns:
> 
> - If we enable DIAGNOSTIC, then we should also enable DEBUG, as it also
>   covers many relevant diagnostic checks.

Historically, DIAGNOSTIC was enabled and DEBUG was not. Usually (but maybe
my view is wrong) DIAGNOSTIC enables debug/consistency checks while
DEBUG enables debug printfs. DEBUG can make the kernel way more noisy,
and is not necesserely usefull to detect a problem (which is what
DIAGNOSTIC is about).

KASSERT() & friend is enabled by DIAGNOSTIC, this is mostly what I'm
concerned about.

> 
> - Alternatively, it should be clearly defined what goes under DEBUG,
>   i.e. what is considered a "heavier check".  I think code diverged in
>   a way that the difference between DEBUG and DIAGNOSTIC is small.
> 
> - Since performance is degraded and -current users concerned about it
>   will need to compile their own kernels anyway - I believe LOCKDEBUG
>   should be enabled as well.  Perhaps LOCKDEBUG should become a part
>   of DEBUG - it is at least clearly a "heavier check". :)

I'm not in favor of LOCKDEBUG by default, for reasons already stated here.

> 
> - There MUST be a very clear indication to users - a warning in a visible
>   place that the kernel has diagnostic options enabled, and performance
>   is significantly degraded.

we already have a /etc/motd which contains warnings on HEAD. this could be
added here.


> 
> - Obviously, defined policy/responsibility to disable these options for
>   release kernels.  In fact, if we go this way - then options should be
>   removed from all MD kernel configs and managed in MI src/sys/conf/std.

I'm not sure this is doable: some ports may want to keep DIAGNOSTIC in release
branches, while others may want to exclude DIAGNOSTIC from some kernels
on HEAD (for example because of space constraints).

> 
> > I know that DIAGNOSTIC was commented out so that someone could install
> > a HEAD snapshot and run benchmarks out of the box, but as a side effect
> > a lot of but are left hidden and only show up when someone tries
> > to run a Xen kernel (which still have DIAGNOSTIC). See kern/45051 for
> > another one.
> 
> Many developers do use these options (e.g. I always enable all options
> when developing something), but some bugs just occur rarely.  For example,
> at least few developers were running diagnostic kernels, but did not get
> the assert reported by drochner@ (also, many developers simply do not
> upgrade their kernels that often).  PR/45051 is also a rare case - I have
> added that assert in pool(9) subsystem a year ago, exactly for a reason to
> get these kind of reports.  Surely many had run diagnostic kernels in a
> year time, but it might need specific workload to trigger.

Actually lots of DIAGNOSTIC checks firing on Xen, also fire on
GENERIC when built with DIAGNOSTIC ...
So I guess not so many peoples runs DIAGNOSTIC kernels ...

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--