The Essence of OpenBSD
Pages: 1, 2
ORN: It seems that with most systems driver developers make up most of the kernel team. Is this true with OpenBSD? Who writes most of the drivers? Do you usually use other BSD drivers when possible? Do you sometimes use Linux drivers as an example?
drahn: This brings up the frequent problem with open source development: getting documentation for hardware. Most of the time, if a *BSD driver is available, it is much, much better to port that driver or at least start with that driver and make improvements where possible, hopefully feeding the changes back to the original authors.
Sometimes when hardware documentation is not available, the only source of information is from Linux device drivers. GPL prevents us from taking their driver and releasing it as a restriction-free driver. It is sometimes possible to read the GPL driver, reverse-engineer what the hardware does, and then write a driver based on that understanding.
jason: Systems driver developers are a big part of the group, but not the biggest. The largest group is probably the folks who handle third-party software "ports." Most of the drivers written from scratch are written by a very few people within the project. The majority of drivers come from the other BSDs, but this is not always a trivial undertaking. For instance, FreeBSD has a completely different disk subsystem, CAM, which makes porting SCSI drivers from there difficult. They also have a very different API for DMA handling. Linux drivers, besides the GPL copyright issue (which I will not address), are difficult to follow because of the use of "magic constants": using hex digits instead of symbolic names. In some cases, they can be used as supplements for vendor-provided documentation, but because of different kernel semantics and magic constants, it's difficult to use them more directly.
miod: This is probably true. A lot of developers are involved only in kernel code, or mostly in kernel code (like myself). A large part is also focusing on third-party applications (port collection), and then a few developers are working mostly on userland. However, there are no fixed boundaries; people work on what they like to work on.
As for driver support, a significant set of drivers is shared between the main three BSD flavors, regardless of where they originated; this is, for example, the case for a lot of network card drivers, the USB subsystem, and crypto hardware. I usually do not look at the Linux drivers, but the hardware I write drivers for is generally either not supported by any free operating system, or only by other BSD flavors.
ORN: As OpenBSD has grown, have you lost any vital developers, and why?
drahn: I was lost to OpenBSD for over a year, several years back. I have seen two main causes for loss of developers: One, lack of "free" time on the part of the developer, where they no longer have enough time in their life to continue working on OpenBSD. Two, personality conflicts.
ORN: What books were most helpful to learn how to do your particular specialty?
jason: The Design and Implementation of the 4.4BSD Operating System is a must, but primarily I have spent my time (and still do!) reading datasheets for various chips and then figuring out how they relate to existing drivers. I've learned a few things about datasheets:
- Prerelease glossies are useless (they don't even make good litter liner).
- Preliminary datasheets (before the chip is released) are problematic, since inevitably, something in the design changes and they forget to update the datasheet.
- Bad datasheets are almost as bad as no datasheets.
ORN: Sun has been defiant about providing UltraSparc III information, so that you could make a proper port to Sun's newest processor. The Linux developers that have added support for this processor signed non-disclosure agreements (NDAs). De Raadt has said that he will not do this. Has this tarnished your image of Sun, and has there been any progress towards adding a port for this processor?
jason: What really irks me is that the Linux guys did nothing to help the community at large by signing the NDAs. It's nice that a very small group of Linux folks can fix bugs in the bowels of their kernel, but not having docs generally available hurts the community. The Linux folks had the power to do this right a while ago.
My image of Sun is that of many other chip vendors who think that keeping the documentation closed somehow helps their business model. So they are not tarnishing my image of them at all, only living down to it, unfortunately.
miod: I am sure disappointed by this situation, especially since Sun has not been known for double-speak like this in the past. Like probably most of the UNIX-contaminated people out there, I have been happily using Sun hardware for years, and I am still satisfied with this hardware, but the company seems to be getting more and more unfriendly (to say the least) and I don't know if I will continue using Sun hardware over the next few years, if only because I do not trust the hardware manufacturer as I used to five or 10 years ago.
ORN: What systems other than OpenBSD do you use, and why?
jason: I have one Windows machine ... It runs Quicken and Quickbooks exclusively (mainly because the alternatives do not fit my needs).
miod: Being a Unix hardware collector, I use a lot of non-OpenBSD systems, such as AIX, IRIX, and Tru64 UNIX; also, NetBSD on some platforms which are not supported (currently) by OpenBSD. However, in my day-to-day use, the only operating system I use besides OpenBSD is IRIX (SGI's version of UNIX) because SGI workstations have amazing graphics capabilities, and IRIX is the only operating system that fully supports this hardware. And I really enjoy hardware OpenGL screen savers. I also used to run OS/2 happily for 10 years ('90-'99), but it feels like it was in a previous life!
drahn: Well, since a lot of the work I do is on Apple Macintoshes, I occasionally boot Mac OS 9/X on some of the machines. Sometimes this is to play games, sometimes this is to run software that is not available on OpenBSD. While I have had at least one PC-based machine since 1992, I have never had Windows installed on any of my machines.
ORN: If OpenBSD didn't exist, what would you most likely be using/doing?
jason: Probably working for a stuffy government contractor or something. Not having nearly as much fun. =)
miod: Well, OpenBSD evolved from NetBSD, and I had been a satisfied NetBSD user before I switched to OpenBSD in late 1997. So, if OpenBSD did not exist, I would probably be using NetBSD instead.
ORN: OpenBSD has used CVS practically since the OpenBSD project started. Has CVS scaled well for what you do, or have you been looking into other solutions?
drahn: CVS is a fair tool. However, it has its own set of problems. Some of the OpenBSD developers were hopeful when we first saw OpenCM. However, that system appears to have its own set of problems. Currently, it is not more desirable than CVS.
miod: Despite a few minor annoyances, I am pretty satisfied with CVS. I know that a few developers have been considering other software, especially the promising OpenCM, but I have not been researching this myself. CVS matches my needs so far.
ORN: It was noted in a message by De Raadt that i386 and the PowerPC are not capable of doing per-page execute permission. Are there any plans to have a workaround that might be slower, but provide something similar to this?
miod: As far as I know, there are already workarounds (in 3.3 for PPC, post-3.3 for x86), which are a best effort to compensate for the lack of real X bit in these processors.
drahn: OpenBSD has an implementation of W^X protection for
-current. The current version has been implemented with no
noticeable slowdown. Some issues have been raised that may require some
adjustment to the current strategy.
We have plans for slightly modified version of this strategy for PowerPC; however, coding for that has not started.
ORN: Two AMD Hammer (x86-64) boxes have been donated to the project so that OpenBSD will support this architecture. What are your thoughts about this processor? Is it better from a security standpoint than x86 (non-executable pages of memory, etc.)?
drahn: The Hammer implementation is much nicer in that it has a per-page execute bit; this allows W^X support with no special tricks. Other than this and a >32-bit address space, the machine is basically just a standard PC. OK, I have to admit that at the current time the fastest processors available are PCs (x86 based).
ORN: Have you considered writing system programs in a safer language than C?
miod: I don't know much about the "new" languages of the last few years (such as Ruby or C#). But among all the languages I know, I feel C is the best-suited for systems programming, if only because it provides very few barriers, thus allowing you to do exactly what you want to do. The drawback is that you have to be very careful in what you do, and sincerely, I'd rather have to be twice as more cautious than trusting a compiler and its runtime library to do this work for me. A friend of mine likes to describe OpenBSD as "craftsmen work," and I agree with him here. Craftsmen pay attention to all the details, and only C will let you check all the details.
drahn: The problem with writing code in most languages other than C is that what they really do is limit what the developer is able to do, or wrap the actions with additional code. This often comes at a cost of code speed or obscures the code.
ORN: Do you have a need for more developers, and if so, what do you need help with?
jason: Drivers. I could really use more good hands in the network driver area.
drahn: More developers would be good; however, managing new developers can actually use up more time than writing code ourselves. This is done with the hope they stay around until they are actually useful.
miod: I think every software project needs more developers -- the more, the better. In the OpenBSD case, a few filesystem, memory subsystem, and non-TCP/IP network gurus would be really appreciated, although every area of the whole system is worth working on.
ORN: What 10 improvements would you like to make to OpenBSD in the future?
- SMP-capable PowerPC
- ARM port?
- Firewire Support
- 802.11g support
- Additional PowerPC hardware support (non-Apple)
- Improved RAM support on PowerPC
- Improved support for newer Apple machines
- Mac PPC audio support
- Mac PPC laptop suspend support
- i386 W^X improvements, which are in progress
George Peter Staplin is a student in Utah whose own programming focuses mainly on computer graphics. He works mostly with open-source variants of Unix, including OpenBSD.
Return to the BSD DevCenter.