The Uniform Driver Interface—why wasn’t it adopted?
Every now and again, I come back to looking at device drivers and driver-writing, and I wonder why there is not some common interface for device drivers. What would the world be like if we could write a device driver for Linux, and be able to use it on FreeBSD without modification? There was a project called the Uniform Driver Interface, which aimed to create a common specification (both API and ABI) for drivers such that they could be used portably between operating systems. In other words, a device manufacturer could create a device (say, a SATA chipset) once, and it could then be used by Linux, FreeBSD, NetBSD, OpenBSD, Haiku, Windows, OS X, or any other operating system that chose to implement the UDI specification (or, honestly, any generic, OS-independent driver specification).
The Free Software Foundation objected to UDI for various reasons. Mostly, I think, it was because they were afraid that people who are not them would choose to use drivers that were non-free. As I’ve written about before here, there are people who think that forcing people to use free software is somehow freedom—and I will not go into it in any great depth here, because I have done that in the past. Suffice it to say that forcing anything is not freedom; it cannot be freedom. So, the Free Software Foundation, I think, was really afraid that they would have to do more work to be able to stick to their own requirement of using 100% free software on their own computer systems. (And hey, Roy, if you’re reading—I’m not saying that the FSF is wrong, and I’m not putting myself in a position opposite of that of the FSF. I suspect you think so anyway, but hey, I just figured I would point that out.)
Even if the free software operating systems did not adopt the UDI specification, why didn’t proprietary operating systems? This is perhaps the most puzzling thing to me. It seems that in this event, none of the operating systems—free or proprietary—did what would have made sense. After all, even if only Apple and Microsoft adopted a common device driver specification, that would save a lot of time, effort, and improve user experience all the way around. Apple users would be able to use all the hardware that Microsoft users could use—and the inverse would also be true. The amount of time that device driver authors would have to spend writing and debugging driver code would go way down—free software driver authors would be able to write a driver once, for example, and all systems (including free software systems that chose to support the specification) would benefit.
I could see an objection of a driver specification that was binary-only. However, UDI was not—it mandated an ABI so that drivers that are built for a particular platform were binary-compatible with operating systems on the same platform, but it also mandated an API, so that drivers would be source compatible to any operating system that implemented the specification, on any platform. That by itself would seem to me to be positive motivation to hardware manufacturers to release the source code to drivers so that they can support operating systems that are on platforms that do not exist yet, or have not been considered (or have been considered to be nonviable or unsupported platforms).
So, I have to wonder why a common device driver specification was never implemented in various operating systems. It would seem to be a common sense thing, especially given that there are so many operating systems. It would make the coexistence of operating systems a lot easier, and it would promote choice. It might encourage bits of proprietary code on free software operating systems, but it would also enable people to drop the excuse that “free operating system x does not support device y”, and would as a result potentially increase the number of free software programs and operating systems in use, even if there is a minor cost in terms of certain drivers. And those drivers could always be replaced—a common driver specification would make it easier to understand the structure of drivers generally, and make it easier for lawful, clean-room reverse engineering to be done on those drivers.
Imagine, for example, if drivers for graphics cards, TV tuner cards, video and audio encoding/decoding cards, modems, storage chipsets, motherboard chipsets, USB chipsets, IEEE-1394 chipsets, graphics tablet devices, touch screens, debugging interfaces, network devices, and so forth were all written to a common specification, it would reduce the amount of code which needed testing. It would increase user choice in both hardware and operating systems—something which I still hold is quite likely the most valuable freedom we have. It would increase reliability, since the users of Windows, OS X, Linux, the various BSD systems, and other, not-so-mainstream operating systems would be able to run the same driver code and collectively supply debugging information and perform testing in a multitude of environments. It would increase security, because then common code that is well-known could be used on all platforms and not just the one it was written for. It would do for device drivers what POSIX has done for user-mode application software. I do not believe that I could be convinced that this would be anything other than a good thing.
Also, it could bring back old operating systems. Imagine what life could be like, for example, if OS/2 had a “UDI driver” written for it, and it could then take advantage of newer drivers never intended for it. Or any other very old operating system which is no longer supported and could still be useful, for any of a number of reasons…
lefty.crupps 5th March 2010
While it would be cool, the Linux (kernel) people have said there would ‘never’ be stable APIs on Linux, and any driver that wants in should release its code to the Kernel team. So, no matter what theFSF says, the kernel team won’t let it happen (currently; never say never, eh?).
But for Microsoft to do this would mean that they are willing to accept standards (very unlikely) and those standards would then mean users would be free to go elsewhere with their data, apps, and hardware. Apple doesn’t much like standards either, for this same reason: lock in. If these companies were so sure that their OS and hardware was great enough to never leave, they maybe would accept this stable, cross-OS API. But, neither are that sure of themselves, and both Apple and Microsoft have worked hard for years to lock users into their respective platforms.
So, the closed, proprietary OSes won’t do this out of fear of losing the install base (and with it, market share); The GNU/Linux people don’t seem to want it for various technical and licensing reasons; this seems like an uphill battle to me (but also like a great idea).
Where do the various BSDs stand on the issue?
Steve Carlton 5th March 2010
Amen to all of the above. I’ve been waiting for UDI for years now. Sooner or later something has got to give because the progress of the uP’s is not slowing, but accelerating. The old BIOS malarky is not going to hack it much longer.
Jonathan 5th March 2010
I had no idea that such a project had ever been proposed. As you lay it out, the choice between a common UDI and a series of proprietary drivers seems blatantly obvious. Further, you’re right in pointing out that the FSF does occasionally shoot itself in the foot by demanding entirely free software all the time, even when to use such would be to disadvantage the end user. As developers, we need to remember that it is the end user who we serve, and that no amount of hand waving about morals and principles will excuse software that performs poorly on the user’s system.
Stuart Norman 5th March 2010
Even better would be a Universal Driver Interface layer in every OS, but the driver would be in a rom chip in the hardware. No need to download or acquire a driver in any way. The driver would just report the function to the UDI and everything would work. And it wouldn’t matter whether the driver code was proprietary or ope source.
Math 5th March 2010
Because drivers by standard are written mainly for Windows and Microsoft do not other OS to work nicely.
oiaohm 5th March 2010
Linux and freebsd both had UDI support in 2001. SCO added it in 2003. UDI was even mainline Linux kernel for a while.
Simple fact FSF had nothing todo with UDI dieing. No drivers came. I repeat no drivers came. If hardware makers were not going to use it there was little point keeping it around.
Linux kernel and Freebsd kernel disregard FSF in regard to firmware. This is where you have a problem say FSF has anything todo with the driver matter. Lot of hardware makers have gone the path of loadable firmware with open spec interfaces.
Reason firmware allows them to keep their secrets. Open spec interfaces allow better driver optimization without having to use an extra wrapper like UDI.
Also there are advantages to this. Firmware screws up mostly it contained to the hardware its on. So complete OS does not die.
Basically Linux kernel developers have a issue with closed source binaries in kernel space where if they screw up can completely stuff the secuirty of the OS. NVidia is to blame a lot of this.
Yes closed source driver makers have avoided using provided interfaces and gone for Linux Kernel internal interfaces because they are faster. Then tried demanding they stay stable.
Basically go over the http://udi.certek.com/f-participants.html list and see if you can find 1 UDI driver. Yep there are none. Then Nvidia and other closed source drivers for Linux and Freebsd not once did they release a UDI driver.
These days there is a new common driver systems. cuse and fuse shared between FreeBSD and Linux and others. Advantage it don’t need kernel space. So secuirty of OS can be maintained. Since it closer to posix OS’s it works better. There is also UIO in the Linux kernel that is used in the embed space.
So basically between fireware, cuse, fuse and uio there are stable api’s to build closed source drivers on Linux. Yet where are the drivers.
“What would the world be like if we could write a device driver for Linux, and be able to use it on FreeBSD without modification?” Were have you been it already happens. Sorry 5 years too late to the party.
oiaohm 5th March 2010
I really missed one.
cuse covers all char devices from user space.
buse covers all block devices from user space.
fuse covers all filesystem from user space.
Only things not covered by this is network cards and devices you cannot directly talk to from userspace.
cuse and buse interfaces follow posix so any posix OS can have them implemented. Even better freebsd follow the posix agreement of 2001 of supporting applications built using linux syscalls since those are stable.
Basically there is your cross platform neutral driver. Built using only Linux syscalls running in user space and interface by cuse or buse or fuse to setup their block devices. Covers all of the posix world bar Mac OS X.
The idea that something equal to UDI does not exist today is wrong.
All USB and Firewire drivers could be done using cuse and buse other than printers and network devices. By the way userspace printer drivers are also stable across lots of platforms so not being able to do them in cuse and buse is not a issue. libusb makes the USB bit simple. Firewire has the same interface on all posix os’s. Makes life a lot simpler.
PCI and PCI-e some are supported issue is interp handling but that is improving. Motherboard chipset for memory control basically always kernel space and out question to handle any other way.
UIO support in Linux that is not across other POSIX OS’s at this time can do network card and all the PCI and PCI-e drivers that cuse and buse cannot do.
Basically UDI died. New stuff grew up in it place. Basically stop spreeding the myth that cross platform driver tech does not exist. It does hardware makers choose not to use it.
Yfrwlf 6th March 2010
Agreed. Standards = freedom. Why it was never done and why there isn’t a community push to implement it? That’s beyond me. Even if the Linux distros had some silly reason for not wanting it, users should still want it.
Michael Trausch 7th March 2010
@oiaohm: I was aware of FUSE. I didn’t know about the existence of BUSE and CUSE, though. So, I suppose between (F|B|C)USE and NDIS, we cover /most/ types of drivers.
Are there ports of (B|C)USE to Windows and OS X? I know that there is a FUSE for Mac, and I think (if memory serves) that there is one for Windows as well.
Thanks for your comments—it would seem that there was more out there than I was aware of. Of course, userspace drivers come at a cost on operating systems where they are not the norm (e.g., µkernel systems where they take into account that that is their primary [indeed, only] type of driver and make things very efficient for going back and forth). It’s still nice that there is the ability for them. I will take a look into those things.
Michael Trausch 7th March 2010
@Jonathan: I could not have said it better myself. There is a lot that we can learn from just stopping and listening to common sense. Life’s too short to stand at the end of a spectrum and scream until we keel over from high blood pressure or something like that.
Michael Trausch 7th March 2010
@lefty.crupps: Yes, I am pretty well aware of the Linux kernel’s policy and why they want to have drivers in-tree. Though, that brings up an interesting point: a specification could even be as loose as an ABI/API spec based upon, say, the Linux kernel at a given point in time. Though, that would also probably very heavily influence other operating systems that implement the interface.
There are, as oiaohm mentioned, other portable userspace driver implementations for various types of drivers. I’m going to have to look into them and perhaps write up on what I find next.