oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

What Is Darwin (and How It Powers Mac OS X)
Pages: 1, 2, 3

XNU--Darwin's Kernel

A good starting point for discussing any OS is the kernel: the core of the OS that provides access to and scheduling for the underlying hardware that's available. To fully appreciate Darwin, you'll want to know some of the details associated with its kernel, XNU, which is an interesting blend of the Mach 3.0 microkernel that's been modified to include portions of FreeBSD inside the kernel space for performance reasons. Mach's foundations go back to Carnegie Mellon University out of Pittsburgh while FreeBSD is a descendant of BSD (Berkeley Software Distribution), which hails from--you guessed it--the University of California at Berkeley.

XNU is the result of an effort to combine the strengths of two different approaches to kernel design: the monolithic approach and the microkernel approach. While the jargon might already sound complicated, the primary difference between the two is pretty simple and basically boils down to what programs run inside the kernel itself and what programs run in userland. Whereas monolithic kernels typically are defined by a fairly complete set of rich abstractions that access the hardware all within the same address space, microkernels tend to provide a fairly minimal set of services within the kernel and use daemon (server) processes running in userland for the rest of the core services.

monolithic kernel microkernel
Conceptual views of monolithic kernel (left) and microkernel (right) design

There are frequently debated trade-offs between the two approaches, but just about all of them eventually come back to efficiency as the pivotal point of discussion. The tightly coupled nature of a monolithic kernel allows it to make very efficient use of the underlying hardware, which is a very desirable thing. The drawbacks of monolithic kernels, however, are that they're very difficult to write and a single mistake in the kernel's code can crash the entire system.

Microkernels, on the other hand, run a lot more of the core processes in userland. This approach simplifies the actual kernel design and can provide a great deal of stability in the system. Unfortunately, these benefits come at the cost of the microkernel having to pass a lot of information in and out of the kernel space through a process known as a context switch. Context switches introduce considerable overhead and therefore result in a performance penalty.

You're probably beginning to see the underpinnings of the debate that unravels when you start to make a case for one kernel design over the other. Perhaps the most famous of all these debates was between Linus Torvalds and Andrew Tanenbaum. Torvalds makes a case for the monolithic kernel, while Tanenbaum defends the microkernel approach. You can read the original messages that were part of a world famous flame war back in 1992 here. (It's fortunate for us that the decision for Darwin's kernel has already been made.)

The Rest of Darwin

We've been harping on XNU for a while now, but there's still a lot more to be said about Darwin besides its kernel. Some of the most notable features worth mentioning include its facilities provided through I/O Kit, its Virtual File System (VFS), and its networking support.

I/O Kit

Darwin's I/O Kit (Input/Output Kit) is a Mach-based device driver framework. It's modular, extensible, and offers a true plug-and-play solution for dynamic device management. Unlike Cocoa, which is written in Objective-C, the I/O Kit is written in a restricted subset of C++ that's based on the Embedded C++ specification. Much of the justification behind the choice of C++ as a language for I/O Kit was based upon C++'s mature compiler and long-standing support for systems programming.

Fitting into the Mach-based kernel methodology, device drivers derived from I/O Kit are special types of kernel extensions that provide the information necessary to handle a device or entire family of devices. Unless you're writing device drivers or interfacing to hardware at its lowest levels, you probably won't need to work with I/O Kit. But just in case you do, I/O Kit Fundamentals is a great starting point.

Pages: 1, 2, 3

Next Pagearrow