Re: bin/38044 (netbsd-4 won't build cleanly with -DLOCKDEBUG)

["Greg A. Woods; Planix, Inc." <woods%planix.ca@localhost>]

The following reply was made to PR bin/38044; it has been noted by GNATS.

From: "Greg A. Woods; Planix, Inc." <woods%planix.ca@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost,
 ad%NetBSD.org@localhost
Subject: Re: bin/38044 (netbsd-4 won't build cleanly with -DLOCKDEBUG)
Date: Sun, 17 Feb 2008 00:52:59 -0500

 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 of
 > 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  
 > 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>