Quality of FreeBSD

Robert Watson rwatson at FreeBSD.org
Thu Jul 21 23:58:19 GMT 2005

On Thu, 21 Jul 2005, Alexey Yakimovich wrote:

> Even for "dynamic problems" you can have your code generating detailed 
> logs, including time, pid, thread id, cpu, function, memory ..., and 
> have them analyzed later by some script. But this not my main point 
> here, in this thread.

Instrumentation is very expensive at run-time, and substantially changes 
timing, especially in the network stack and network-related device 
drivers, so will often close race conditions by changing the timing.  We 
have an extensive instrumentation system named KTR(9).  If you're 
interested in giving it a try, you can find out more here:


This page is primarily targetted at tracing locks, memory allocation, and 
context switching, but you can also trace I/O, bus operations, VFS 
operations, and a range of other things. While my web page doesn't talk 
about it, as it's generally focused on micro-tracing of kernel events, you 
can also queue the event stream to disk using alq(9).  The man pages have 
more information.  There are some neat tools, such as Jeff Roberson's 
schedgraph, for managing and rendering trace results.

The downside, is of course performance and perturbing of the events. 
Adding trace operations in rapid firing events, such as context switches, 
lock operations, and so on, even if they're disabled at run-time, has a 
huge performance cost.  As a result, the trace mechanisms are added via 
compile-time options for the kernel.  There's some interest in introducing 
run-time instrumentation, although the focus of that has primarily been 
related to run-time adaptation of kernels between UP and SMP, in order to 
avoid lock costs on an SMP-compiled kernel running on UP.  Even then, the 
performance perturbance is a big issue for tracking subtle races.

> All thoughts in the mails of this thread, developers as well as users, 
> seem to me so right, so true. But I would like to repeat my main point: 
> From my personal experience, maybe I'm wrong, but what I see close to 
> me, FreeBSD project is loosing a lot of users, I don't know anything 
> about developers, but it seems to me true too. No users no developers no 
> project.

I appreciate your concern, but at least from looking at the committer 
count and commit rates, FreeBSD is gaining developers rather than losing 
them.  Likewise, while users come and go, reports from organizations like 
Netcraft have tracked a moderate to substantial increase in FreeBSD use 
over the last few years.  If you then throw in indirect consumers of 
FreeBSD as a result of FreeBSD-derived operating systems, such as Apple's 
Mac OS X, Juniper, etc, the numbers become rediculously large very 

None of this is to say quality and a focus on quality aren't important, 
just that while your concerns are valid, I think there's a lot of detail 
to this that isn't as immediately obvious.

Robert N M Watson

More information about the freebsd-stable mailing list