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 <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
