BSD DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


The Essence of OpenBSD

by Cameron Laird and George Peter Staplin
07/17/2003

A half-dozen OpenBSD principals participated in emailed interviews on their work. Here's what they had to say:

O'Reilly Network: How did the team form?

Different members came at different times, so a couple of us will answer.

deraadt [Theo De Raadt]: Well, the history of when I started OpenBSD might be well-known by most. Early on, the first team members were people who were unhappy with NetBSD. In particular, quite a few Swedish people joined ... about a year later a security focus started in the project, as some people from a Calgary company called Secure Networks started helping, and then ... after that I have kind of lost track, since it has been almost eight years ....

dhartmei [Daniel Hartmeier]: I didn't know about OpenBSD back when it was started (1996, if I'm not mistaken); I learned about the split from NetBSD later. I joined the team in June 2001, when my work on the new packet filter was imported into the source tree. First contacts with other developers were based on email and ICB (Internet Citizen's Band), and the rules and rites are passed informally from the veterans to the newcomers. Once a year we meet at a "hackathon," which is how I met most people for the first time in real life, to discuss new ideas and make plans for the next year. When people have shown the required skills in the past and are interested, they get invited to these events and recruited. There are no formal positions filled; basically anyone with skill and time is welcome to work in the areas he or she is interested in. There is a strict peer review process where the more experienced developers review any changes to the source tree before they get committed, and provide feedback. As one or several developers spend more time in a particular source part, others will consult them when working on those parts, like maintainers.

jason [Jason L. Wright]: Can't speak to the time before I was brought in (Jan. of 1998), but for myself, I tried installing NetBSD and OpenBSD on an ancient machine at the time (a Sun 4/330), and neither one worked. I hacked around the problem by installing a previous release and then read through the change logs to figure out what happened, and submitted a bug report (with patch) and got mail from some Theo de Raadt dude asking if I wanted an account. My life hasn't been the same since. Generally, if you prove yourself to be good at something needed in the project, you'll eventually get asked. There's a sort of mentoring process where a new developer is brought in and given limited rein until he/she is "proven."

miod [Miod Vallat]: I cannot answer for the 1995-1999 years, since I was not "officially involved" in OpenBSD back then. I myself was invited to join the OpenBSD team in early 2000, after I had been working independently on my own, and have had good communications with several developers. One can say that there are, roughly said, two ways to enter the team: either by providing something new and valuable to the OpenBSD project, or providing valuable and reliable help on various tasks for some time until an existing team member gets bored of having to finish the work for you. In both cases, this is a recognition of your merits and the quality of your work. New developers regularly show up, and can be long-time users that want to contribute in return, as well as newcomers with good skills ... there is no preselection criterion.

drahn [Dale Rahn]: Back in 1995, it formed by Theo (one of the founders of NetBSD) breaking off from NetBSD and forming his own development group.

I (Dale) had worked with Theo on NetBSD because earlier that year Theo, Chuck Cranor, and myself all had developed NetBSD ports for the Motorola MVME147 (embedded computer). I had never been closely associated with NetBSD, but I had used their software on i386 and Amiga for some time. Before releasing my MVME147 port I had never had much communication with the developers. BTW, I had been along for the ride with *BSD since the beginning; I purchased my first PC machine to run 386BSD 0.0 in 1992 before graduating from Purdue.

Theo had seen my work on my MVME147 port and knew that I had access to hardware and documentation since I worked at Motorola. He was working on porting (then OpenBSD) to the MVME162 board and wanted it to run on the MVME167 (very similar boards which were faster than the MVME147), but a new serial driver needed to be written for the MVME167. Theo convinced me to write the driver for the hardware and when I had it mostly working, he invited me to be a developer.

Team additions normally occur when someone new shows up and appears to have skill or potential to develop the necessary skills. When they seem to be submitting decent changes, and seem responsible, they are invited to be developers. Their changes to the tree are monitored closely, to prevent errors from being introduced into the tree and to direct the developer's abilities and improve the quality of future changes.

ORN: What do you mostly work on?

dhartmei: Primarily, I'm working on the packet filter, both the kernel and the related userland parts. As a consequence, I'm familiar with the TCP/IP stack and networking code, and can help with problems in there. I have done some work in other parts and try to help with tasks that require help from many developers, like the ongoing replacement of unsafe string-handling functions.

jason: Drivers. Floating-point emulation. Drivers. The sparc64 port. Drivers, and a tiny bit of userland stuff (usually to go with kernel stuff, like the bridge, that I've written).

miod: I am mostly working in the kernel area, although I contribute userland changes from time to time. My main area of work is the support of old, dog-slow, obsolete, and generally not-worth-a-dime-anymore architectures, such as the various Motorola 680x0-based systems, as well the VAX systems, for example. However, I have been working on every architecture supported by OpenBSD.

Supporting obsolete architectures help ensure the overall portability and correctness of the operating system code, and in fact, this work often turns into janitor work: a design peculiarity of a specific architecture or a run-time strange behavior forces me to check how our code behaves on all of the supported architectures, and make the behavior consistent.

drahn: UGH. What areas have I not worked on (scratches head)? Currently my main tasks are port maintainer for Mac PPC (Apple PowerPC hardware) and security improvements.

Most of my recent work has involved the W^X (Writable xor eXecutable) security enhancements to OpenBSD. The goal of this effort is to make it much more difficult, if not impossible, to allow a hacker to inject code into a machine and then execute it. Adding this security feature to i386 has involved many changes in the compilation environment and the kernel to allow us to bend some of the typical assumptions into a form that allows W^X protection.

Other pending projects include Advanced Power Management (APM) sleep support for Apple laptops, W^X support on PowerPC, developing audio drivers for newer Apple machines, improved PowerPC VM/system calls, PowerPC SMP?

ORN: Do you compare your work to that of others, and if so, how does it compare?

drahn: While it might be interesting to compare my work with other developers' work, it often is quite difficult to compare. The areas I work in tend to be areas where few other developers work; sometimes finding someone to review my code is hard enough.

miod: Developers usually have their own areas of expertise, and know the others' areas. If an area is shared with other developers, or two areas share many concepts or code, developers have to communicate with each other and share their work. It's not an obligation, but it's the only way to do reliable work. And there are always new ideas to borrow from your peer's work.

Pages: 1, 2

Next Pagearrow





Sponsored by: