DragonFly BSD: UNIX for Clusters?

People often talk of the BSD family as "the three BSDs," meaning Free-, Net-, and OpenBSD. For the last four years, another has been making solid progress. David Chisnall looks at DragonFly BSD, the fourth major BSD.

Like this article? We recommend

Like this article? We recommend

One of the defining features of open source communities is their tendency to fork. Anyone who wants to can take a copy of the codebase and start working on their own version. In the BSD community, the best known fork happened in October 1995, when Theo De Raadt forked NetBSD to create OpenBSD. Since then, OpenBSD has surpassed NetBSD in terms of userbase.

In 2000, the FreeBSD team branched the 5.x series in CVS and began developing it as an unstable branch. This new 5.x branch had an impressive list of proposed features: mandatory access control from the TrustedBSD project, UFS2, a new volume manager, background fsck, a dynamic devfs, and fine-grained kernel locking.

The June 2003 release, 5.1, was still nowhere near the stability expected of FreeBSD. Users had a choice of either staying with 4.8 and keeping a stable OS or moving to 5.1 for new features. Most chose to stay with 4.8. Matt Dillon, one of the FreeBSD kernel developers, decided that several of the approaches being used in the 5.x series were dead-ends, and in July 2003 forked the stable 4.x codebase to form DragonFly BSD.

The 4.x FreeBSD Foundation meant that DragonFly has been a solid platform from the start. DragonFly, like the other BSDs, imports code from other members of the family when it makes sense, such as the malloc() security features from OpenBSD, parts of the WiFi subsystem from FreeBSD, and USB code from NetBSD. In spite of this, development has been pushed in some unique directions.

Not a Microkernel

Matt Dillon originally became known as an Amiga guru and author of the DICE C compiler for that platform. It is not surprising, then, that DragonFly would gain some inspiration from the Amiga.

The Amiga implemented inter-process communication via message passing. Because the Amiga did not have protected memory, this could be implemented by passing a pointer rather than requiring an expensive copy operation. As such, many would not class the Amiga kernel as a “pure” microkernel. In spite of this, the clear abstraction between components made the code easier to maintain and reason about.

DragonFly uses a similar model. Message passing primitives are the main interface between kernel components and between the kernel and userspace programs. Matt explained some of the rationale behind this decision:

The Amiga kernel was designed around small but powerful APIs and messaging. Having a small, well defined API for a subsystem results in fewer bugs, easier to find bugs, and code sustainability. When you have a complex API, you restrict the number of people actually able to program to it, and you increase the number of new bugs introduced through lack of a complete understanding of the API.

The message passing model is used in a lot of places. The networking stack is now multithreaded, and uses the messaging interface for all communication between components. Socket function by user space programs invoke a message sending system call to pass the data into the top of the network stack, and the same mechanism is used to hand it down through the layers until it hits the network interface.

Once the packet arrives at the driver layer, things begin to look a bit more like a traditional UNIX system. Matt described the reasons for this, saying:

I did build in-kernel messaging mechanisms into DragonFly that are similar to the Amiga messaging model, but I stopped short of trying to use messaging for device driver, filesystem, and system call interactions. The bald truth of the matter is that (insofar as I know) all UNIX code bases today except mach are designed around a direct-call model, and short of rewriting the entire code base from scratch a direct-call model is what we have to use. Additionally, using a fully abstracted messaging model for everything introduces huge-performance nerfs into any system.