The BSD Device Driver Problem

The General Problem

From my perspective, one of the most difficult tasks for OS developers is maintaining current hardware support. New hardware seems to come out almost every quarter, rendering current hardware obsolete almost as soon as it’s purchased. It’s plainly obvious that new operating systems don’t have much of a chance of ever staying current in their hardware support. However, I think most people forget about just how hard this task remains for OSes that have been around for a long time.

The BSD Problem

Consider the various BSD operating systems. At this point, there are actually five distinct OSes carrying the BSD label (Free*, Net*, Open*, DragonFly*, & Midnight*), with various derivatives and offshoots. Each of these projects have their own communities and ecosystems, but they do not all have the same (nor similar) levels of support and financing backing them. As a result, choosing hardware for these systems has to be done very carefully in order to avoid wasting money on tech that amounts to little more than paperweights.

Of course, I know that the desktop isn’t the main focus of any of the main BSD projects. Still, there have been various bits of effort put into fixing the wifi driver deficiencies and porting Linux graphics drivers with varying degrees of success to the three original BSD projects. In fact, there’s been an effort by the FreeBSD community to directly target improving their support for laptops. While I can appreciate the effort, I can’t help but wonder what happens when the project moves on to their next point of focus & hardware support dwindles again.

In the early years of development on the open source graphics stack, FreeBSD & the Linux kernel actually shared a code tree dedicated to the DRM (direct rendering manager) system. Unfortunately, the pace of Linux development of the code far exceeded the pace of FreeBSD development of the code. Consequently, the inevitable conclusion was for the code-sharing arrangement to end and Linux pulling the DRM code into the kernel tree. Today, the BSD community finds itself constantly playing catchup by porting Linux graphics driver code over to their respective OSes. This development path clearly isn’t sustainable for the long haul, so the various BSD projects continue to remain behind in graphics device support. Additionally, the Linux world is moving to a new display server which will force the rest of the *nix ecosystem to either adopt more Linux-ism or be left behind. And make no mistake, most WILL be left behind.

A Potential BSD Solution

Ok, well that all sounds pretty bleak. Surely, something can be done to improve the driver situation, right? Well, yes -something CAN be done. The best idea that I can muster is for the whole BSD ecosystem to unify behind one device driver architecture and grow a new tech stack supported by ALL BSDs. While it would be best for each BSD project to contribute members to focus solely on this project and how it interfaces with their respective projects, that’s not strictly necessary. Another way to accomplish this is for people who want to get involved to actively communicate with the BSD projects to get a unified list of what each project views as absolutely necessary in a device driver stack, then get to work building it. Once it gets to a point where it’s ready for early consumption, each BSD project can start the process of migrating to the new driver stack.

Now, why would any of the BSD projects bother with this? Various arguments can be made for why this is a bad idea. Sure, each project is independent and enjoys doing things their own way. Of course, none of the projects want to deal with external code that may disrupt their current levels of support for their top platform target tiers. Yes, each project has their own coding standards that may not necessarily be compatible with each other’s.

Those are all valid points, and I’m sure that there are many more. However, consider what could be gained from such an approach. With each project having a substantially smaller developer pool than Linux has, sharing the workload would be a massive win here. The need for shims and Linux compatibility layers would evaporate. The development pace could be faster than what’s standard in most BSD projects, which would help with close the gap between hardware release and hardware support. However, development could still happen at a slow enough pace to allow for design to have a high priority. Additionally, the rest of the *nix world will be one step closer to having true independence from the Linux ecosystem -which has proven on numerous occasions that it doesn’t really care how its developments affect the rest of the *nix community.

Conclusion

So, where does that leave us? Well, in a bit of a mess, honestly—but not one without a way out. The hardware support situation across the BSDs is rough, no doubt about it. It’s fractured, reactive, and way too dependent on what Linux decides to do next. But it doesn’t have to stay that way. If the BSD community can find a way to align—even just enough—to build and maintain a unified driver stack, then we might actually stand a chance of turning this around. It won’t be quick, and it won’t be easy. There’ll be pushback. There’ll be growing pains. But if we’re serious about the future of BSD as more than just a server curiosity or a platform for niche devices, then this kind of cooperation is exactly the sort of uncomfortable step we need to start taking. Otherwise, we’re just going to keep writing pieces like this—year after year—wondering why nothing ever gets better.