ONLamp.com    
 Published on ONLamp.com (http://www.onlamp.com/)
 See this if you're having trouble printing code examples


Behind DragonFly BSD

by Federico Biancuzzi
07/08/2004

For years we had FreeBSD for performance, NetBSD for portability, and OpenBSD for security. Now a new project, focused on innovation, has worked very hard and is ready to release its first version: DragonFly BSD 1.0. Federico Biancuzzi interviewed some of these innovators to discuss their interesting points of view.

Matthew, could you give us a short history of the steps that brought you from being a FreeBSD developer to becoming the DragonFly BSD project creator?

Matthew Dillon: Well, while at Berkeley (1985-1989) I used CSRG's BSD 4.3 quite a lot and even did a little driver work for the Perkin-Elmer we had to play with. I had already done considerable work in the embedded world. Working with Berkeley's UNIX really piqued my interest in UNIX and operating systems in general. After graduating I began using Linux, and contributed to some of the early Linux kernel work. But once the USL lawsuit was resolved and the BSDs started gaining momentum I returned to my roots and began actively using FreeBSD. Later on I began using it on BEST Internet's machines, which of course resulted in a large number of bug and patch submissions, which eventually led to a commit bit as a FreeBSD committer. However, that relationship had always been quite fractious, primarily due to the inability for some FreeBSD committers to accept the work on its face. For example, I had to fight tooth and nail to get the VM changes between FreeBSD 3.x and 4.x into the tree.

However, while committer relations have always been an issue, DragonFly split off from FreeBSD-5 over major architectural differences, not anything else. We really do feel that FreeBSD-5 is taking the wrong approach to SMP and building something that is so complex that it will ultimately not be maintainable. We think we have a better way.

Hiten, Jeffrey and Joerg, could you introduce yourself?

Joerg Sonnenberger: I'm a 20-year-old student of mathematics and spare-time programmer. I have investigated different fields of CS in the past years and got a bit bored last year. That's why I'm here.

Jeffrey Hsu: I was one of the early FreeBSD committers 10 years ago, working in the kernel and on many of the compiler and language ports. I did the first JDK port to FreeBSD. Recently I've done a lot of work on the FreeBSD networking stack, mainly adding SMP locking and improving TCP. When Matt started DragonFly, he invited me to join and I've been here ever since. I find the friendly project atmosphere a refreshing change.

Hiten Pandya: I am a 17-year-old and I live in the United Kingdom (UK). I have been working on FreeBSD for a good five years, since 1999, and as a committer since summer of 2003. I was aware of DragonFly and Matt's plans at about the end of May 2003, i.e., before it was publicly announced, and I have worked on it since its inception in early June 2003.

Related Reading

BSD Hacks
100 Industrial Tip & Tools
By Dru Lavigne

I still work with FreeBSD people often but my primary interest is in the advancement of DragonFly because of the adopted methodologies. I really do not have anything against FreeBSD, because without that, we would not have DragonFly. For me it is just a matter of preference and I like to work with a smaller (committer) team because it is easier to get work coordinated and actioned without too many interruptions. At the end of day, it's all about advancement of technology and ideas. Politics has little to do with it. My interests roughly scale from Operating Systems to Clustering. I have worked on various projects, including Apache HTTP, Jakarta Tomcat, xMach, IBM's Journal File System for Linux and OS/2, DCE UUIDs, SCTP network protocol, and such. Over the last five years, I have written numerous amounts of technical documentation, device drivers, subsystems and embeddable systems on *BSD and Linux. In the past few years, I have also worked extensively on Bioinformatics applications such as BLAST and Phylogeny and Annotation tools, thus my interest in developing SSI-type technology among others, like Checkpointing.

What is your role in the project?

JS: I'm doing a lot of the driver and low-level hardware work e.g. by investigating and backporting the various changes of FreeBSD CURRENT. Another field is keeping the system compiler up-to-date.

JH: I do mostly the same things as before: adding MP support to the networking stack and improving the TCP algorithms.

HP: My role in DragonFly is hard to describe in a few words. I try to do whatever is necessary for the Project like coordinating developer effort, help with features, liaise with BSD and Linux developers, try to keep peace and clear any misconceptions held by others, stop people from unwanted ranting on the lists, etc., etc. If there is work that needs to be done but no one has picked up the ball due to constraints, I generally tend to them. Basically, anything and everything; starting from core kernel work to documentation, web site updates, anything.

I have worked in these areas many times before so most of them aren't a problem. I usually read CS papers to see how DragonFly's approach compares to others, what interesting things we can take from NetBSD, OpenBSD, etc. Additionally, I try to stay aware of developments in the CS industry from time to time.

While we are on the topic of who's who, I would like to thank the following people: the DragonFly Team — especially David Rhodus — for providing support whenever possible. I typed this up on a notebook donated to me for DragonFly work by Chris Beuchler and Scott Ullrich.

Who do you think should try DragonFly BSD?

MD: Anyone at all.

JS: Anybody with a certain understanding of computers and UNIX. I'm not sure whether I want to use DragonFly for a productive system now, but it runs fine most of the time and has a decent performance. I'm re-commenting it to Linux and other BSD users and haven't received negative replies yet.

JH: Anyone who likes Unix(tm) should give DragonFly a try. We're based on FreeBSD 4, the most stable and the fastest FreeBSD version we've ever released as a project (the next closest one in terms of quality was FreeBSD 2.2.5). In DragonFly, we work hard to maintain backward and forward compatibility with FreeBSD 4. We even have two compilers in our system, gcc2 and gcc3, and all the infrastructure in place around them to generate either FreeBSD 4 binaries or the newer gcc3-format binaries. In fact, I do much of my DragonFly kernel development on a FreeBSD userland and just compile and copy the kernel over and reboot.

HP: Anyone can try DragonFly, whether it fits their needs or not is up to them to decide. Currently, the DragonFly community is pretty much a mix of various types of people, some are taking the "hmm, interesting, let's wait-and-see" approach, while others are dissatisfied with SMP methodologies adopted by FreeBSD or are interested in upcoming features of DragonFly.

Note, we are not trying to vouch that DragonFly is very stable right now, because there are still a lot of unstable changes to be made. SSI is definitely going to be one of many, although most people have found it reasonably stable for their work.

What main advantages does DragonFly BSD provide against Net/Open/FreeBSD?

MD: Well, our primary competition (if competition is even the right word) is FreeBSD. FreeBSD had always been on the forefront of implementing new ideas and if DragonFly is about anything it's about implementing new ideas. We are not trying to support every platform under the sun (NetBSD) and while security is important to us, it isn't a focus like it is in OpenBSD.

What DragonFly aims to provide is a SMP-capable infrastructure that is inherently easy to understand and develop for. Our primary advantage over FreeBSD is in the methodologies we have chosen to follow in the development of the kernel's infrastructure. We feel that in the long term our infrastructure will be easier to develop and maintain and lead to levels of stability that rival and surpass the mid 4.x releases of FreeBSD.

We have some long term goals, such as SSI (Single System Image) support, which are going to be years in the making, and we have chosen to develop a number of models, such as a new threading, messaging, and IPI messaging model, which we feel will be superior to the other BSDs, and Linux, particularly when used in an SMP environment.

JS: At the moment, we have the speed of FreeBSD 4 and the ongoing work to support SMP. Ask me at the end of the year and DragonFly might be the IA32 reference for performance.

JH: We have the most advanced networking stack and have even more improvements in the pipeline, so the disparity will only get larger as time goes by. In addition, our MP support is a departure from the outdated SMP model. Today's MP hardware is not symmetric, so if you were to add MP support to an OS today, why not use techniques that are more suitable to today and tomorrow's technology? Our networking stack is designed to scale to large number of processors, more than the 2 or 4 that SMP hardware can effectively run on today.

HP: It would not be right to say FreeBSD is a competition because our code-base started with that as the root; but I will not deny that we have a very practical and sane goal-set in mind.

Our advantage from my point of view is that, we are blending in technology and code from other BSDs and Linux (not directly taking code in the latter case). Net/Open/FreeBSD have their own individual advantages, portability, security and implementing new ideas, respectively.

For e.g., NetBSD has made some interesting advancements in their VM system and in its network stack, we occasionally take a peak at them and see how those changes can be better integrated with our model. Most of the times, it would mean tailoring the original code to a large extent, but at the end of the day, the result would be much better code and performance.

Pretty much what Matt said about long term goals, the end result should be practical and not losing out on single-processor performance. We plan to clean out the unnecessary items that we have inherited and create smaller, faster and efficient replacements. We believe that creating a powerful abstraction (like LWKT messaging) is much more important than just implementing a subsystem because everyone else in the neighborhood is doing it.

It seems that you have chosen a development cycle more similar to OpenBSD than FreeBSD, why?

MD: I wasn't comparing development cycles between the BSDs so it is coincidence. But possibly it is coincidence borne out of necessity. We do not have the developer resources that FreeBSD has and so our release cycle is going to be slower (perhaps twice a year instead of every 4 months), and we cannot maintain half a dozen release branches in parallel so end-users will have to upgrade to keep up with developments. We do plan on having a stable tag that at least tracks security changes between releases, however.

JS: We don't have the resources to follow a CURRENT + STABLE + RELEASE system like FreeBSD does. It would also slow down development a lot, which is not very useful in the current state of DragonFly.

I don't think we will announce releases every half year, but that isn't decided yet. It puts pressure on us as team, which is both positive to get stuff ready, but also means overhead.

HP: Not by choice as Matt said, but the OpenBSD development and release cycle is good to keep most bugs out of the system, in my opinion. Secondly, we lack the resources and hardware to keep up with tons of release cycles. Not a bad time to say, the team members would appreciate to have different sorts of hardware if possible.

Right now, the only people with any powerful hardware is David Rhodus and Matt. Both have been very generous in providing resources when possible to help development.

Would DragonFly use a branch for ports like OpenBSD does?

MD: Probably not. We have been in rigorous discussion over what kind of ports/packaging system we want to have. We have already agreed that the core ports/packaging system visible to end-users should be a binary system rather then a source build system. This isn't to say that sources would not be made available for customization purposes, just that most users just want to get a port/package installed as quickly as possible. While the BSD ports/packaging system does have a binary install capability it is insufficient for our needs.

The other thing we've decided on is to give the ports/packaging system the ability to isolate installations. One of the biggest problems one has maintaining a large multi-use system is when upgrading a package for one particular subsystem. Upgrades to the packages for one subsystem can interfere with packages already installed for another, and sysops cannot afford to have upgrades break unrelated subsystems. So, for example, we want there to be isolation between the packages associated with, say, the mail subsystem, and packages associated with, say, a workstation user. The two subsystems might install the same package or might install different versions of the same package... we want that to work.

JS: No. I want to reduce interactions between ports and base system, FreeBSD partly succeeded in that part. OpenBSD has a lot of stuff in base and needs such branches e.g. to support updates of the package management tools.

Had you considered using NetBSD pkgsrc for external software instead of maintaining your own ports collection?

MD: We are considering everything. Nothing is set in stone yet.

JS: Yes, we have. I like pkgsrc, because it would save us an enormous effort for setting up a few thousand apps. But pkgsrc also has the problem of support too much and being slowed down by that. If a FreeBSD ports is outdated, the pkgsrc port is even more likely to be.

Someone sent a fake mail on 1st April 2004 featuring a Theo de Raadt interested in LWKT multiprocessor technology. That was funny, but have you had any contact with the real de Raadt now that OpenBSD is working on SMP introduction?

MD: For some reason I usually respond to good April Fool's jokes before I realize that they are April Fool's jokes, so I actually responded to Theo on that one. We did have an interesting discussion but Theo is totally focused on security, and while security is important to us, it isn't our focus.

How does LWKT compare with FreeBSD 4.x and 5.x, NetBSD 2.0 and OpenBSD SMP technologies?

MD: Well, neither NetBSD nor OpenBSD are really designed for SMP. I don't say that in a bad way ... It's simply that with so many platforms to support it's difficult to do a proper ground-up SMP implementation in OpenBSD or NetBSD. FreeBSD was able to do a ground-up SMP implementation primarily because they only had support for two or three platforms (but of course we in the DragonFly project feel that FreeBSD went off in the wrong direction when they did that).

IMHO, I believe LWKT to be a far superior environment for SMP (and UP as well) over the traditional process model that the other BSDs use and over the mutex-centric model that FreeBSD-5 uses. That's one of the primary reasons why we forked the DragonFly project off. LWKT provides an extremely efficient and scaleable programming environment on both UP and SMP systems. FreeBSD-5 has pretty much abandoned UP performance.

JS: It is simpler to use and less error-prone. The token abstraction often simplifies code compared to the mutex model used by FreeBSD 5 and NetBSD. The thread handling itself is very neat too, because it doesn't try to be smart, but simple. No fancy preemption mechanism other than the well-known soft interrupt handling, no ping-pong of kernel threads between CPUs. This is important for performance and makes the system more deterministic.

AMD and Intel have announced some plans for dual core CPUs. Until they become available we can play with Intel HyperThreading technology. What type of interaction is there with LWKT?

MD: Well, we inherited the hyperthreading capable code from FreeBSD-4 when we forked so DragonFly does run hyperthreaded. I have never liked hyperthreading, though, because it results in a nonsymmetrical set of CPUs, which greatly complicates the scheduler's job. FreeBSD-5 has been trying to schedule for hyperthreaded CPUs for over a year now with very little success (i.e. threads still get scheduled inefficiently). DragonFly does not try to schedule specifically for the hyperthreading case but LWKT does a pretty good job and we are at least on par with FreeBSD. We are not going to focus on hyperthreading, though, because it involves an enormous amount of scheduler work for very little gain.

Hyperthreading was a good idea at the time, but it is clear that the future is going to be multi-core.

JS: At the moment, HTT is handled just like another real CPU. We can avoid some pitfalls, because we are not tempted to use spinlocks. But there isn't any preference in the scheduler yet and we know of some problems with NICs, so HTT support is in a bit of flux right now.

Would multithreaded network stacks like that of FreeBSD 5 be possible with LWKT?

MD: FreeBSD-5 multithreads its network stack using a reentrant mutex model. We are taking an entirely different approach. Instead of making the network stack reentrant we are partitioning the work on a connection by connection basis and distributing it across multiple threads. Each thread operates independently of the others and operates without needing mutexes or network-specific locking of any sort. Jeffrey Hsu has been doing most of this work and we feel that it is already far superior to the FreeBSD network stack model. Among other things, we pay very careful attention to the L1/L2 CPU caches and our model partitions the work between CPUs and focuses more on maintaining locality of reference for the PCBs and less on load-balancing. The result is far less duplication of data across CPU caches on an SMP system. We believe that this will result in superior performance in heavily loaded environments.

JS: Well, why would you want to do that? I'm following the changes in the FreeBSD 5 network stack to allow fine-grained locking and those are huge. You could do something similar with tokens, but that would be expensive and slower than the mutex system. The work Jeff put into our tree to partionate work across the CPUs is much more promising and I'm investigating the adoption of the model for other parts of the kernel.

JH: Sure. Multithreading our networking stack in the form of running netisr interrupts on multiple CPUs was the first thing we did. To this day, FreeBSD still does not have multiple TCP threads running on multiple CPUs. So we're actually ahead here.

Polling vs. Interrupts: With FreeBSD you can use polling to improve network performance on busy interfaces. What about DragonFly? Do you plan to introduce polling support in other areas?

MD: We inherited the polling code from FreeBSD, so we have it. Polling is not really needed for more modern NICs, though, because the cards have their own burst/batch/idle timers and can generate a far lower interrupt rate then the actual packet rate.

JS: We already inherited the polling support for the network interfaces, yes. I'm not sure whether it is really worth the effort. The high interrupt rate is reduced by smarter hardware. Most Gigabit-Ethernet devices support that and it greatly reduces the need for polling. Other parts of the system are similar and the overhead of polling has to be carefully evaluated. ATA polling sounds interesting though :)

JH: DragonFly has the same device polling that comes with FreeBSD.

Is DragonFly BSD TCP/IP stack hardened enough to avoid Paul Watson's RST attack?

MD: I believe that Jeff committed some work recently to narrow the possibility of that attack.

What about a bit more of randomness for numbers like dynamically allocated TCP ports and processes PID?

MD: I don't see much point in doing that, though Theo would probably disagree with me. There are only 65535 ports and it takes very little time try them all. We have a randompid sysctl option (inherited from FreeBSD), and I have no objection to adding a random-port option. But it isn't a priority.

JS: I don't believe randomizing PIDs gives us any advantage in security. Hiten committed a patch for the randomization of TCP ports.

Do you have any plan to add memory protection systems?

MD: We will be adding support for the NX (no-execute) page table bit, but I'd rather not try to use segmentation tricks to get non-executable stack support for earlier CPUs. I am on the fence, actually. I could probably be persuaded to hack the segmentation for earlier CPUs but I would prefer not to. The real problem is the inherent insecurity of C code. If it comes down to it I'd rather modify the compiler and libraries (even if it makes the result inefficient) than modify the operating system. We already have the propolice patches integrated into our GCC and it is turned on by default in gcc3.x (DragonFly installs both gcc2.95.x and gcc3.x in the base system). Our compiler currently defaults to gcc2.95.x and will remain defaulted to it for the first release, but by the second release we will have moved entirely over to gcc3.x. There are other tricks one can play, such as randomizing malloc() addresses and such. I am perfectly willing to implement library tricks to reduce the possibility of a hack.

JS: We already ship with a propolice-enabled compiler and base system. Separation of write and execute bits on a per-page base might be added later, but it is not a priority. For AMD64, it is easy to support, for IA32 not.

Is anyone working on virtualization extensions to have multiple independent systems running at the same time? And what about the support of VMware or free virtual machine like Xen?

MD: There are one or two people that have been playing with Xen and DragonFly.

JS: Supporting Xen is a very nice project on its own. As far as I know, nobody is currently working on it. This might change after the system API has stabilized a bit and the native support for AMD64 / x86-64 is ready. Supporting extensions like User-mode Linux is not a priority and I don't think we would add it, because it is far too special.

HP: The idea of porting DragonFly to run over Xen was Kip Macy's. He and I discussed the idea for a good four hours or so and had pretty much things figured out. He has done the hard work of porting and adjusting a lot of the drivers, but there are still a few more rough edges that need to be sorted. I have not been able to do much there apart from getting it running because I got tied up with more important things with regard to DragonFly.

DragonFly runs fine on VMware since Day One. Well, except for a few hiccups that we had, two of which were due to some VMware errata items, and one was an ATA timeout issue that also disappeared with the latest version (4.5.1 or something). I have successfully run DragonFly on VMware with Linux and Windows as the host Operating System.

As for VMware running on DragonFly, that's a totally different ball game.

There are various way to create a cluster. You can use a special software like SETI@home does, you can use some external software that interact with the kernel like openMosix, or you can modify the way the kernel manages resources, removing differences between local and remote. How would DragonFly clustering work?

MD: One of our major goals is to implement SSI (single-system image) clustering. Our goals go far beyond Mosix.

Ctrl+E let's you save a running software session and restart later. Who had the idea? How does it work? Is this feature usable for clustering or virtualization?

MD: This was Kip Macy's idea. He saw that the core dump support was severely lacking in many areas. One thing led to another and we realized that we could walk the memory map, save modified anonymous memory, and record the inode numbers for open files, and thus actually save enough information to make simple programs checkpoint-able.

The checkpointing feature serves several purposes. It is in fact good enough to checkpoint simple programs (where the only open descriptors are associated with files, not counting stdin, stdout, and stderr). It can be used for debugging -- by checkpointing a program and then restoring it in a gdb environment. And we are using some of the checkpointing infrastructure APIs elsewhere in the kernel just to clean things up. Finally, by maintaining this relatively simple module we have a basis in place for the implementation of process migration in a future clustered environment.

It should be noted that DragonFly does not cluster (at the kernel level) yet. We are a few years away from achieving that goal. But it is our goal.

HP: We have plans to checkpoint network connections and the whole system, in the future. It was being discussed between Kip Macy and me.

The installation tool runs from a LiveCD. Are you considering creating a LiveCD with a complete system like FreeSBIE or KNOPPIX to promote DragonFly?

MD: I think at most we might pre-install an X environment. The problem with creating a "complete" system is that half the packages become obsolete the day after the release is burned. 99% of the people who would use such a release are also operating in a networked environment with Internet access, so my feeling is that whatever packaging system we come up should integrate network access and provide an incremental binary update facility.

JS: I'm planning to do that, yes. I was thinking about adding the important bits to the build-infrastructure, but it was decided to wait until our package system is ready. One important feature before this would happen is adding transparent decompression support either via a special userland lib or directly in the kernel. That's why KNOPPIX can support such an amount of software and what is currently lacking in DragonFly.

Do you plan to release binary updates?

JS: Later, yes. Having a binary package system and having a binary update system complements itself. Both are very useful for mass deployment and are a major part of any enterprise system.

HP: Yes, there are plans to release binary updates for security and upgrade. Quite a coincidence, because I, Joerg, and David Rhodus were discussing this just a few days ago. A lot of people just want to update their system and be done with, i.e., they don't care about source distribution but only in the quality of the update process (i.e., a smooth one).

Compiling ports and packages, world builds, take a very long time, they do not provide a marketable advantage. Most people do not have anything to do with the source code, so giving them the ability to update their packages using a binary system is a must; just think how long it takes to compile OpenOffice or any desktop system.

It is about time that someone in the BSD camp revolutionized system updates. One of goals focused on by the DragonFly Team is to implement (or at least organize) an update system that can be managed by just using PGP-signed binary updates; i.e., most of the base system packages do not require recompiling because they are seldom changed. The only part which the user would need to recompile is the kernel. Of course a few utilities which depends on kernel structures would be tagged specially for rebuild but the rest can just be updated using a binary update system.

Of course, nothing is set in stone, yet, but this sort of Binary Update system would become most helpful when DragonFly reaches its stability period (in a year and a half, I predict), in which ABI incompatible changes will be done once in a blue moon. The core project members (including David Rhodus) are discussing the issue.

DragonFly BSD is a young project and I'm sure you'll be happy to find new developers. What type of contributors are you looking for? Which area would you like to add manpower to?

MD: We are looking for a broad spectrum of developers and users/testers. Primarily we are looking for people who already have a good idea what they want to do rather then people looking for something to do, e.g., people who say, "I'd like to build an advanced checkpoint interface," versus people who say, "I'd like to help out with the project but I don't know where to start." Everyone is welcome, though.

JS: The userland development is currently pretty stalled. We could need additional manpower to cleanup the source tree, merge changes from the other BSDs, and start writing our threading library.

For the kernel, there is also a lot to do. One advantage of a small team is the reduced chance of conflicts :) If you want to contribute, send us a small note or come to our IRC channel, we don't want to waste your and our time by duplicating work.

HP: Sure, more people to help out is not a bad thing, but right now we need people who have some sort of a focus on what part to play in the big picture. Of course, we could use people who want to write documentation for DragonFly, pretty much like the FreeBSD Handbook or the NetBSD Guide. That does not mean we will be ignoring the "I need guidance" types; I for one do not mind educating more people about the DragonFly kernel or documentation framework or anywhere we could use help.

To summarize, most of the outstanding tasks require the developers to have some sort of expertise in the area or ability to pick up things quickly. That applies to the documentation as well.

Since the time I gave DragonFly a documentation framework, Justin Sherrill has done a lot of work on it like importing the FreeBSD Handbook and modifying it for us; but in order to add more DragonFly specific content, one would need to know it properly in order to produce precise and resourceful documentation; of course the Team members will try their best to help the volunteers.

Are you going to use a drastic solution to fight the new XFree license? For example, using only freedesktop XOrg?

MD: We consider X to be a third-party program, so it has no direct effect on the distribution. My personal feeling is that we would take a wait-and-see attitude to see what comes out of the XFree flap.

JS: We have an overwrite port for X.org floating around, but this doesn't affect us that much. I have read a lot of the license agreements in XFree86; the change is not that big, as long as you don't want to sell CDs like OpenBSD. Even then, you might have to do it anyway.

Do you have any idea to replace sendmail with something more modern?

MD: I'd like to integrate a second MTA into the base system and perhaps even default to it. Postfix maybe. Sendmail is fairly difficult to maintain.

JS: It's a question of time. Personally I strongly prefer Postfix over Sendmail, but I have neither the time nor the need to push any change.

HP: That might happen. See, once a package system is developed, we plan to compartmentalize the various parts of the base system so that we can provide packages like MTAs in a better way.

Can we expect to see a web server in the base system?

MD: Probably not, or if you do it will be a very simple one. Apache is too often updated to be a good candidate for base-system inclusion.

JS: I wouldn't count on it.

HP: I highly doubt if that will happen; if you see our answers to the Perl question, we are trying to reduce the amount of third-party items in the base system unless they are highly important, like a system compiler.

What is the status of IPv6 support?

MD: It should be working. We had some issues with connect failing but they should be worked out now. The IPv6 code needs to be rewritten from scratch; the original KAME code (I think I have the reference correct) was, and still is, a huge mess.

JS: There wasn't much effort to keep up with KAME development, partly because it's very difficult to merge changes when you only have lots of snapshots and have to sort out the important changes from the noise.

JH: We have the same IPv6 code that's in FreeBSD. I was in Tokyo last week at the Network World/Interop BSD BoF to reach out to the Japanese BSD user community and met with some of the KAME team members who expressed a readiness to cooperate with us in updating our IPv6 code to the latest KAME version, so our users can look forward to even better IPv6 support.

HP: IPv6 works fine, most issues were resolved. As from the development and update point of view, it needs thought and the whole thing is sitting at the very bottom of our list. The KAME work is hard to stay on par with, but some of the KAME developers are very nice and helpful.

What is the plan for IPSEC? Is there any problem with crypto import/export because Matthew lives in the USA?

MD: No, crypto doesn't seem to be a problem in the U.S. any more. IPSEC is being maintained but as with IPv6 it's a huge hack in the system. Currently we are doing no new work in the IPv6 arena but, certainly, any work the other BSDs do with IPv6 will be looked at closely.

HP: It is pretty much sitting in the same boat as IPv6. They are low priority right now because other things in the kernel need to be stabilized and cleaned up.

Are you going to remove Perl from the base system? If so, why?

MD: We are definitely removing build dependencies on Perl, so we don't need Perl to build the system. We haven't decided yet whether we are going to remove Perl from the base. It isn't that we don't like Perl. The real problem is that Perl goes through so many incompatible changes that the version in the base system inevitably winds up becoming obsolete and interfering with newer versions of Perl that people might want to install.

JS: Perl is a big system and still changing a lot in incompatible ways. Just look at the various ports in FreeBSD, which support either Perl 5.6 or 5.8. The same holds true for GCC, but having a compiler is a much integral part. Most dependencies on Perl are already gone. Both buildworld and buildkernel work without Perl. There still some Perl scripts in our source tree that have to be replaced first.

HP: Pretty much what Matt said. It is better to keep dependency on third-party applications down to a bare minimum. There are plans to improve upon our release framework so that we do not need to keep third-party applications such as Perl and Sendmail in the source repository, and they can be just fetched at release/ISO build time.

One can argue why we would keep a dependency on the Internet for a process such as release builds; but since 99% of the people who will do release builds have a decent connection to the Internet, that argument effectively becomes a moot point.

You have just imported GCC 3.4 in the tree and applied propolice patches. Don't you think that propolice should be included in GCC itself?

MD: I do. Propolice isn't useful unless people use it, and the GCC folks do not have anything remotely similar on offer. If they do not like the propolice patches then they should create APIs within the GCC framework to make it easier for the propolice people to hook in the features.

JS: Yes, I hope it will be part of it one day. It is difficult to maintain GCC, every additional patch increases that burden.

Federico Biancuzzi is a freelance interviewer. His interviews appeared on publications such as ONLamp.com, LinuxDevCenter.com, SecurityFocus.com, NewsForge.com, Linux.com, TheRegister.co.uk, ArsTechnica.com, the Polish print magazine BSD Magazine, and the Italian print magazine Linux&C.


Return to the BSD DevCenter.

Copyright © 2009 O'Reilly Media, Inc.