From owner-svn-src-all@FreeBSD.ORG Wed May 15 02:12:44 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B3359250; Wed, 15 May 2013 02:12:44 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 397D3DF0; Wed, 15 May 2013 02:12:44 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (OTWAON23-1176242366.sdsl.bell.ca [70.28.8.190]) by elvis.mu.org (Postfix) with ESMTPSA id 2770D1A3D04; Tue, 14 May 2013 19:12:23 -0700 (PDT) Message-ID: <5192EF00.3030700@mu.org> Date: Tue, 14 May 2013 22:12:16 -0400 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Will Andrews Subject: Re: svn commit: r250411 - in head/sys: conf kern sys References: <201305091628.r49GSI33039873@svn.freebsd.org> <518F320D.3070304@mu.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcel Moolenaar , jhb@freebsd.org, svn-src-all@freebsd.org, alfred@freebsd.org, attilio@freebsd.org, src-committers@freebsd.org, Jeff Roberson , svn-src-head@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 02:12:44 -0000 On 5/13/13 12:58 PM, Will Andrews wrote: > On Sun, May 12, 2013 at 12:09 AM, Alfred Perlstein wrote: > >> Can we just admit to ourselves that tweaks to debugging macros/printing >> and WITNESS are our kernel developer's "bikeshed zone" and get over the >> fact that people's needs may diverge and changing non-default behavior in >> non-critical paths is not going to be the death of the kernel as we know it? >> >> I could certainly believe that this sort of thing needs long and thorough >> discussion if it wasn't the equivalent of style tweaks to manpages. >> >> Let's leave the long and lengthy discussions to things that matter such as >> standards compliance, ABI, API and really cool performance and stability >> stuff. > > Except that this is *not* the equivalent of style tweaks. I'm not sure how > you got that from Jeff's email. False positive LORs results in people > ignoring all LORs, including real ones. And that impacts stability. > Especially if you are trying to implement performance improvements or fix > bugs; in that case, the LORs act as a safeguard against violating existing > object relationship assumptions. > > Having worked on ZFS for a while, I can say that many (if not most) of the > LORs reported there that are false positives are because the locks > represent objects that are frequently and legitimately related to each > other in reverse orders, due to reuse of object types at different points > in the overall hierarchy. So, I agree that the biggest issue is that > witness's model of comparing strings is insufficient for representing more > complex lock relationships. > > In ZFS, in most cases, the locks are acquired after having already (in > debug builds) checked these relationships. It seems appropriate, > therefore, that witness should be improved by adding the ability to bless > specific object relationships on a per-lock entry basis, so that we > continue to be notified about *legitimate* LORs, at every call site and > between every pair of object types. > > It also seems best to add a new API for this purpose, so that it can be > used regardless of which lock type is being used, without having to modify > all existing lock calls. This does mean that code in FreeBSD would need to > independently verify the object relationships, but doing so is, IMHO, a lot > easier to improve upon than folding this functionality into existing APIs > by adding more arguments. > > --Will. > Sure WITNESS should be made to a lot of things. One volunteer made it work for a subset of developers without breaking it for the people outside of that subset. Time for the pitchforks and demands that IF YOU TOUCH IT, YOU BETTER FIX IT TO MY LIKING!!! Give me a break already. I highly doubt that Marcel or anyone would object to someone coming forward with this "better way", the problem is that no one will, however they will harp on bikeshedding about it to no end without a problem. Stop blocking, start coding. Start taking a step forward as the gift it is and take time to improve upon it instead of bashing it to pieces. -Alfred