"Development is really fast right now, because of the hackathon in Edmonton. We are testing as much as we can before we commit, but as always during these hackathon processes we really depend on our user community -- to track our changes and help spot the occasional bug we accidentally introduce. We are developing really fast and hard; please help us by testing really fast and hard too."
"The OpenBSD Foundation is pleased to announce that it has completed arrangements with the University of Alberta in Edmonton to host the 2008 Annual OpenBSD Developer's Conference (C2K8 Hackathon) from June 7 to June 15, 2008," stated an announcement by the OpenBSD Foundation, continuing:
"The facility support from the University of Alberta Computer Science Department will provide C2K8 the best facilities yet for the annual OpenBSD Developer Conference. C2K8 will be the 10th annual event of its kind. Previous hackathons have produced tools such as the PF firewall, OpenBGP, relayd and spamd, as well as innumerable critical improvements to OpenBSD, OpenSSH, and related projects.
"This year, the OpenBSD Foundation will disburse approximately $15,000 to support C2K8, enabling more than 50 OpenBSD developers from around the world to attend this important event. The Foundation thanks all who have generously donated the resources to make C2K8 possible."
Jason Wright and Mark Kettenis have spent much of their time at the c2k6 hackathon finishing up support for UltraSparc III processors on the OpenBSD/sparc64 architecture. A number of months ago Henric Jungheim put in several weeks of effort reverse engineering support for the UltraSparc III, then OpenBSD creator Theo de Raadt [interview] put more time into cleaning up the diff and comitting much of it to the source tree. Halfway through the hackathon, Jason and Mark have taken what was not-quite functional code and have it successfully booting into multi-user mode. A couple of years ago there was an unsuccessful attempt to obtain documentation for this processor from Sun [story], so this current effort has had to use the FreeBSD and Linux UltraSparc III implementations as references. Theo explained, "Sun released CPU docs, but that's useless. It is kind of like trying to fix a car engine with the owner's manual. The rest of the hardware is not documented."
Jason points out that not only does OpenBSD run on the UltraSparc III processor, but it is also "self hosting". In other words, it is possible to build an UltraSparc III kernel on an UltraSparc III, and then reboot to that new kernel. This is important, Jason explains, because GCC is very memory and CPU intensive, "it really hits a server hard". He goes on to add that for this reason all the different OpenBSD architectures are built on their own architecture, and that this policy often catches bugs that could otherwise be missed.
Tables are cluttered with laptops, servers, switches, cables and cords as the 2006 OpenBSD hackathon continues in Calgary, Canada. Small groups of developers talk and debate around LCD screens, while others work individually on their own projects. Behind the scenes, a donated 10 megabit wireless connection provides Internet access to all. IP addresses and DNS are provided by stock bind and dhcpd processes running on an OpenBSD server. Among other things, the infrastructure area hosts an HP DL385 with 24 GB of memory that was recently donated by HP, a G5, several Sun Blade 2000's, and an assortment of PowerPC, Alpha and Opteron-based servers. A console server provides serial connections to the servers along with logs of what went on on the serial console, useful for debugging. Power issues on the first day were resolved by evenly spreading the servers and many laptops across the available circuits in the hackathon room. Chris Kuethe explained, "the whole point of the infrastructure is that it's not supposed to be exciting, it's just supposed to be there, like a light switch."
I have spoken with another 28 OpenBSD developers from Turkey, Iceland, Ireland, Germany, Sweden, Switzerland, Denmark, Australia, Austria, Hungary, the US, and Canada. Efforts are being made on ACPI, the VFS subsystem, link-layer authentication, OpenBGPD, tcpdump, XFree86, pf, CARP, dvmrpd as a replacement for mrouted, OpenRCS, OpenCVS, the USB layer, prebinding, ipsecctl, 10 gig Ethernet support, link layer path mtu discovery, several new and improved drivers, amd64 large memory support, new CD and DVD recording features for cdio, improvements to mg, support for new architectures, numerous new and updated ports, and much more.
The 2006 OpenBSD Hackathon, c2k6, is well underway in a conference room at a hotel in downtown Calgary, Canada. The event started yesterday, May 27th, attended by nearly 50 OpenBSD developers from all over the globe. OpenBSD creator Theo de Raadt [interview] is thrilled by what is already proving to be another successful event, "I don't think anybody else does this, developers suspend their lives for a week to focus entirely on just development." Theo explains that he doesn't get much coding done himself at these hackathons, but instead focuses on ensuring beneficial communication between developers, an obvious advantage to assembling so much talent in a single room.
Walking among the cluttered tables, I've been talking with the high energy attendees of this year's hackathon, learning who's here and what they're working on. In this first installment I've talked to 18 developers from France, Switzerland, Germany, the UK, the Netherlands, Australia, Brazil, Dominica, the US, and Canada. They each talk a little about how they discovered OpenBSD and what they're working on here at the hackathon, including introducing new ports, support for SD devices, local OpenCVS functionality, improvements to OpenNTPD, improved SCSI controller support, initial support for the UltraSparc III architecture, and much more. The hackathon continues around the clock through June 2nd.
OpenBSD creator Theo de Raadt began developing OpenBSD in October of 1995. KernelTrap first spoke with Theo back in November of 2001 [interview], around the time that OpenBSD 3.0 was released, discussing much of the early history of the project. The project has continued to offer regular releases of their "free, functional & secure" operating system every six months, with OpenBSD 3.9 made available yesterday, May 1, 2006.
In this latest interview, Theo examines the past five years of OpenBSD development. He also discusses the OpenBSD 3.9 theme song, "Blob!", detailing what blobs are, why OpenBSD avoids them, and how OpenBSD developers work to reverse engineer them. Looking to the development process, Theo talks about recent and future "mini-hackathons", small and focused OpenBSD development gatherings. Finally, Theo also discusses the OpenBSD project's funding issues, and the response to requests for funding from users of the project's OpenSSH software.
Bob Beck is an OpenBSD developer from Edmonton in Canada. He's one of around 60 OpenBSD developers currently working in an undisclosed hotel somewhere in downtown Calgary at the 2005 OpenBSD hackathon [story]. Bob was involved in setting up the infrastructure [story], and was responsible for the annual barbecue at OpenBSD creator Theo de Raadt [interview]'s house [story]. Following these two days of effort that helped to make the hackathon possible, he finally sat down to work on spamd and catch up on email. One of the emails in his inbox caught his attention, leading to a day's effort about which he notes, "some Days end up far far far from where they start."
In the following article, Bob provides a first-person account of tracking down what began simply as a RAID performance issue, but ultimately turned out to be a problem with the idle loop that when fixed resulted in an impressive performance boost. Bob noted, "the idle loop is where the kernel spins when there is no work to do in userland, because of this, it's also where we catch and service many of our interrupts from drivers that may queue work to the device and then tsleep waiting for an interrupt from the card saying the work is done." Bob went on to explain that prior to today's fix, interrupts were handled appropriately when there was userland work happening, but not when there was nothing happening in userland and the kernel was simply waiting for device input/output. Read on for Bob's full account of the day, leading up to the discovery of the problem and the implementation of the fix, including performance numbers.