Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 10 Jul 2002 18:20:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 10 Jul 2002 18:20:30 -0400 Received: from dsl-213-023-043-112.arcor-ip.net ([213.23.43.112]:9960 "EHLO starship") by vger.kernel.org with ESMTP id ; Wed, 10 Jul 2002 18:20:29 -0400 Content-Type: text/plain; charset=US-ASCII From: Daniel Phillips To: Rick Lindsley , Larry McVoy Subject: Re: BKL removal Date: Thu, 11 Jul 2002 00:24:06 +0200 X-Mailer: KMail [version 1.3.2] Cc: Greg KH , Dave Hansen , Thunder from the hill , kernel-janitor-discuss , linux-kernel@vger.kernel.org References: <200207102128.g6ALS2416185@eng4.beaverton.ibm.com> In-Reply-To: <200207102128.g6ALS2416185@eng4.beaverton.ibm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Message-Id: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2079 Lines: 44 On Wednesday 10 July 2002 23:28, Rick Lindsley wrote: > So threading is difficult to manage or even impossible without a global > lock for everyone to use? True -- I suppose that would force people to > think about what they are locking and which lock is appropriate to avoid > unnecessary contention. It would require that the new locks' scopes and > assumptions be documented instead of handed down verbally from > teacher to student. Hear hear! Well, Al at least has made a pretty good attempt to do that for VFS locks. The rest of the kernel is pretty much a disaster. If we're lucky, we find the odd comment here and there: 'must be called holding such-and-such lock', and on a good day the comment is even correct. Which reminds me of a janitorial idea I discussed briefly with Acme, which is to replace all those above-the-function lock coverage comments with assert-like thingies: spin_assert(&pagemap_lru_lock); And everbody knows what that does: when compiled with no spinlock debugging it does nothing, but with spinlock debugging enabled, it oopses unless pagemap_lru_lock is held at that point in the code. The practical effect of this is that lots of 3 line comments get replaced with a one line assert that actually does something useful. That is, besides documenting the lock coverage, this thing will actually check to see if you're telling the truth, if you ask it to. Oh, and they will stay up to date much better than the comments do, because nobody needs to to be an ueber-hacker to turn on the option and post any resulting oopses to lkml. > It would have the side effect of making it easier > for a newcomer to come up to speed on a particular section of code, thus > allowing a greater number of people to understand the code and offer fixes > or enhancements. Yup, and double-yup. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/