From owner-freebsd-current@FreeBSD.ORG Mon Feb 7 18:26:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3738E16A4CE; Mon, 7 Feb 2005 18:26:31 +0000 (GMT) Received: from fly.ebs.gr (fly.ebs.gr [62.103.84.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD95143D49; Mon, 7 Feb 2005 18:26:28 +0000 (GMT) (envelope-from past@ebs.gr) Received: from ebs.gr (root@hal.ebs.gr [10.1.1.2]) by fly.ebs.gr (8.12.9p1/8.12.9) with ESMTP id j17IQQBu041669; Mon, 7 Feb 2005 20:26:26 +0200 (EET) (envelope-from past@ebs.gr) Received: from [10.1.1.200] (pptp.ebs.gr [10.1.1.200]) by ebs.gr (8.12.11/8.12.11) with ESMTP id j17IQOfJ057799; Mon, 7 Feb 2005 20:26:24 +0200 (EET) (envelope-from past@ebs.gr) Received: from 127.0.0.1 (AVG SMTP 7.0.300 [265.8.5]); Mon, 07 Feb 2005 20:26:17 +0200 Message-ID: <4207B2C8.3050002@ebs.gr> Date: Mon, 07 Feb 2005 20:26:16 +0200 From: Panagiotis Astithas Organization: EBS Ltd. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: FW: Call for comments: CoxR, a CVS/mail-lists/BTS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 18:26:31 -0000 Robert Watson wrote: > On Sun, 6 Feb 2005, ALeine wrote: > > >>Oh come, FreeBSD 5.x does have a mutex hell going on, but to say it has >>so many bugs as to require a truck is absurd. :-> A smaller lorry >>perhaps, but a truck - definitely not. :-) It might also be a good idea >>to use an automated spell-check on your pages, I've noticed a number of >>typos such as "divelopers" and similar. > > > I appreciate that not everyone is a fan of mutex synchronization, but > "mutex hell" is a bit of an odd description: most bugs I see getting > reported (and fixed) aren't even locking-related. They're generally a > property of lack of testing exposure for more obscure features or edge > cases that are hard to test for without a wide testing base, such as > edge-case hardware, bugs associated with longer run times, or a recently > introduced feature, etc. Generally speaking, in the last week, I saw a > couple of classes of bug fix fly by in commits, in order of frequency of > occurence: > > - Minor device driver bugs involving alignment, feature mapping for device > IDs, attach/detach bugs, error handling, etc. In one case, the bug was > that a device driver was able to run MPSAFE, but the flag was set > incorrectly to not let it. As usual, a moderate amount of change in > ACPI. This was the vast majority of bug fixes. > > - Network stack logical errors or C-related errors: generally, doing > something wrong with mbufs or routing. Mostly "syntax" and not > "semantics", although a couple of netflow bugs that were more serious > and the result of more broad exposure since its commit (last month?). > > - Scheduling related bugs in ULE -- Jeff MFC'd a number of fixes to > RELENG_5 for the first time in several months, so there was some > backlog, but I think it's not unusual to see a trickle of scheduling > related changes, so isn't entirely unrepresentative. > > - VFS/file system bugs -- a couple were locking related as a result of > Jeff's on-going work to get Giant off of the file system code, but more > were associated with on-going buffer cache work by Poul-Henning. > > While I haven't made any attempt to determine if the last week is > "typical" of long term bug fixes, it was easily on-hand, and the results > are suggestive. Locking, as with other complex changes in the OS, comes > with bugs, but it's hardly "hell" :-). One of the nice things about the > locking approach to synchronization is that it comes with a strong > assertion model: this means you can often find bugs without actually > triggering the symptoms of the bugs, which may be difficult to trigger or > very sensitive to timing. So when there are locking bug fixes, there more > often found through a WITNESS warning than an exercised bug. When I do > complex application pthreads programming, I often wish it had the > threading/locking debugging facilities the FreeBSD kernel has :-). Very informative posting, as usual. Have you considered starting a blog somewhere, so that these longish and of general interest messages can be easily found by non-subscribers to the lists? I have been appreciating the information I get from the blogs of Solaris or Linux engineers and it seems journalists monitor them to spot newsworthy material. If we can get a few of our senior hackers to start blogging a little, it might help spread out the word about FreeBSD. Cheers, Panagiotis