posted by Eugenia Loli on Sat 13th Mar 2004 09:07 UTC
IconToday we feature a very interesting interview with well known *BSD hacker Matthew Dillon over his latest project, DragonFly BSD (also known for his Linux kernel contributions, Amiga C compiler hacking back in the day and the Backplane distributed database). Matthew discusses DragonFly's status, goals, the overall BSD platform, innovation, and more. Update: Added one more question at the end of the Q&A.

1. Please tell us about the general status of DragonFly BSD.

Matthew Dillon: The project has been going very well. We've primarily been focused on the 'guts' of the system during this initial period, and you can get a fair idea of the work that has been accomplished so far by looking at the Diary page on our site.

Most of the work so far has been to operating systems internals. The work has been a combination of new work, like our light weight kernel threading core, plus selective backports from FreeBSD-5 to keep the system's device drivers up to date (e.g. such as the USB subsystem).

From a userland perspective we have maintained a FreeBSD style environment, so DragonFly basically runs everything that FreeBSD-4.x can run. The packaging system probably won't be done until the second release so we are at the moment leveraging off of FreeBSD's ports system for user apps. Everything you'd expect of a BSD system (X, mozilla, etc) is available to DragonFly users.

The first release is slated for some time in mid-June, hopefully before the USENIX Technical Conference. That will be the 1.0 release. We've been fairly careful to maintain as high a level of reliability as possible during development and I think we've done a pretty good job meeting that goal. The first release is intended to be more of a technology showpiece then an integrated end-user platform.

2. Are you using any bits and pieces from FreeBSD-5, or you only strictly importing/exporting to FreeBSD-4 codebase?

Matthew Dillon: DragonFly began as a fork off of FreeBSD-4, because that was the most reliable starting point and because we wanted to do major core pieces of the system quite differently from the direction FreeBSD-5 took. For example, we are focused on more of a compartmentalized threading model to scale to SMP rather then the mutex model that FreeBSD-5 has chosen to use. But the FreeBSD-4 codebase is of strictly limited utility as a source of new code and maintainance updates. FreeBSD developers are doing nearly all new coding in the FreeBSD-5 branch.

So, basically, we are doing the major core pieces of the OS differently, such as our significantly evolved threading and messaging subsystems, but we are also maintaining a FreeBSD-5 compatible (or mostly compatible) device driver API in order to be able to bring in all the excellent device driver work that has gone into FreeBSD-5. It's simple logic, really... we don't have the manpower to be able to accomplish both our infrastructure goals *AND* be able to maintain pace with new PC hardware at the same time. This methodology allows us to proceed on both fronts by focusing our own new work on the infrastructure and bringing in FreeBSD-5's device driver work. This isn't to say that we don't do some of our own DD work, but the vast majority of it is take from FreeBSD-5 by design.

3. What is the primary goal of dragonfly, servers or desktops?

Matthew Dillon: Both. When it comes right down to it the idea of targeting a system to the 'server' is simply another word for 'reliability and scaleability', and the idea of targeting a system to the 'desktop' is simply another word for 'out of the box GUI'. It's not really an either-or deal. All UNIX systems, including Linux, the BSD's, DragonFly... basically use the same desktop components so supporting a desktop environment comes down to being able to provide integrated solutions that work out of the box.

It is extraordinarily difficult to make GUIs work out of the box on PCs due to the wide variability in hardware and peripherals, but at the same time technology has continued to progress over the years towards standards that actually make this easier to accomplish. At some point the standards going in one direction will meet the software going in the other and systems such as Linux and the BSDs (including DragonFly) will be able to approach the out-of-the-box compatibility that took Microsoft billions of dollars of development to accomplish. It isn't a matter of if, it's a matter of when.

4. Do you eye the embedded systems market at all?

Matthew Dillon: It is not a focus. We fully intend to make DragonFly operate in 64 bit environments such as the AMD64 (which is also compatible with the Intel's latest 64 bit announcements even though Intel doesn't like to admit it), but embedded systems are already very well served by Linux and NetBSD and we would prefer to focus on technology rather then platform ports. FreeBSD-5 has had a difficult time supporting the half dozen or so platforms they are trying to work with and I doubt we would fare any better, so I am not even going to try. Eventually, if DragonFly becomes popular enough, embedded systems ports will probably happen, but it's probably several years down the line.

5. How big is the DragonFly team currently? Are you happy with the development pace?

Matthew Dillon: Very happy. The main kernel@ mailing list has 241 people subscribed to it as of now and I have handed out 9 commit bits, with another dozen or so people submitting patch sets outside of that. We have a good spread of developers focused on different subsystems. For example, Jeffrey Hsu is focused on threading the network stack while Joerg Sonnenberg has been focused on the PCI bus and ATA disk driver subsystems, which frees me up to be able to focus on technological infrastructure such as the threading subsystem. It's about at the limit which I can sustain and still have time to do significant programming myself, in fact!

Table of contents
  1. "Interview with M.Dillon, Page 1/2"
  2. "Interview with M.Dillon, Page 2/2"
e p (0)    26 Comment(s)

Technology White Papers

See More