On 16-Feb-08, at 6:50 PM, ad%NetBSD.org@localhost wrote:
Synopsis: netbsd-4 won't build cleanly with -DLOCKDEBUG State-Changed-From-To: open->closed State-Changed-By: ad%narn.netbsd.org@localhost State-Changed-When: Sat, 16 Feb 2008 23:50:07 +0000 State-Changed-Why:Thanks for the PR. This has been fixed in -current: LKMs and user apps are insensitive to the LOCKDEBUG option since it doesn't alter the layout ofkernel data structures. Supporting it as a user compile-time option in already released versions of the system is not a reasonable use of theproject's limited resources, because it's a very unusual configuration.
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.
<woods%planix.ca@localhost>