[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/38044 (netbsd-4 won't build cleanly with -DLOCKDEBUG)
On 16-Feb-08, at 6:50 PM, ad%NetBSD.org@localhost wrote:
Synopsis: netbsd-4 won't build cleanly with -DLOCKDEBUG
State-Changed-When: Sat, 16 Feb 2008 23:50:07 +0000
Thanks for the PR. This has been fixed in -current: LKMs and user
insensitive to the LOCKDEBUG option since it doesn't alter the
kernel data structures. Supporting it as a user compile-time option in
already released versions of the system is not a reasonable use of the
project's limited resources, because it's a very unusual
Sounds like it shouldn't be very hard to backport this kind of
universal support that usr.sbin/pmap seems to have, but it's not
worth my time and effort to help with doing the backport if there's
no interest in actually supporting it in the current release branch
(es) where it would be most useful.
I think it's pretty lame though that you didn't consider the old way
of supporting LOCKDEBUG systems (i.e. compiling the whole tree with
"CFLAGS+=-DLOCKDEBUG" as a valid and very necessary thing, and
instead simply closed my PR summarily without further consulation.
NetBSD-4.0 is still obviously riddled with locking bugs and other
similar issues and it seems to me to be well worth finding and fixing
those that appear in regular use in specific scenarios, as otherwise
SMP kernels are pretty much useless for any kind of production use
where these scenarios otherwise plague them. This finding and fixing
of such bugs cannot seem to be done reasonably without the diagnostic
tools made available by LOCKDEBUG. Supporting LOCKDEBUG diagnostics
in production systems where its need is greatest requires that all of
userland also support LOCKDEBUG too.
This issue with usr.sbin/pmap is obviously trivial to work around.
However the second issue I posted in a followup doesn't seem to have
quite so obvious a fix, at least not to my eyes yet.
Greg A. Woods; Planix, Inc.
Main Index |
Thread Index |