Date: Mon, 07 Feb 2005 20:26:16 +0200 From: Panagiotis Astithas <past@ebs.gr> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: FW: Call for comments: CoxR, a CVS/mail-lists/BTS Message-ID: <4207B2C8.3050002@ebs.gr> In-Reply-To: <Pine.NEB.3.96L.1050207145002.61595I-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1050207145002.61595I-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4207B2C8.3050002>