Subject: Re: DEBUG/DIAGNOSTIC/LOCKDEBUG by default
To: Matthias Scheler <email@example.com>
From: Elad Efrat <firstname.lastname@example.org>
Date: 11/06/2007 16:32:15
Matthias Scheler wrote:
> It's just an example based on experiences from working as operating
> system developer for several years. I've only seen problems hidden
> by debugging kernels for other reasons (e.g. different use of
> memory allocators).
Right. Race conditions, and I think also locking issues, are easily
hidden with changing timing by adding/removing code. I've seen it when
debugging a Systrace race condition about a year or two ago.
That said, I think you can't have a win-win situation, because while
some bugs will be hidden by enabling debugging options, others will be
I'd like to see this discussion going towards thinking up a policy for
when NetBSD should enable/disable the debugging options, rather than
"they will always be turned on/off in all kernels during all stages of
development and users will have to rebuild to toggle".
Here's one, OTOH: Always enabled in -current; disabled when entering
first stages of release engineering to (*before* the tag), after the
tag, the branch will have it disabled, during the entire release
engineering process including the release; -current will have it enabled