UDI is the Uniform Driver Interface. It provides a standard, high performance interface for operating system device drivers, and is standardised at all the important levels – both API and ABI. This means you can take a driver – regardless of if you have the source for it or not – and use it with any UDI supporting system. There is only one problem.
And that is that, unfortunately, UDI has been almost completely ignored
Now, I’m going to admit something straight away: UDI is not perfect. UDI has its flaws; one that has been most commonly levelled at it is that it is complex, and indeed that is true. Complexity is never great, but it is acceptable if it brings features, and it does
However, this is not the main reason people rejected it. They had other ones
“Why should I change my interface when it benefits my competitors?”
This one often came from the Unix companies (And Novell, with regards to Netware). And it is kind of true: If you support UDI, then your competitors will benefit from drivers written from you OS; but the effect is reciprocal: you will also benefit from drivers written from their OS.
It gets silly, however, when they claim “We have leading hardware vendor support! This will benefit my competitors more than me”, because there is only one company who can reasonably claim that – or who could reasonably claim it any time in the foreseeable past and present.
But then, how many of the Unix vendors are still standing today on the basis of their Unix offerings?
“UDI will be slower than my native interface”
OK, maybe. However, know this: UDI was designed to be fast and scalable. UDI pretty much forces you to write scalable drivers. Any benefit you can get over UDI will be small.
And, indeed, when SCO¹ implemented UDI, as a wrapper on top of their native interface, they found it was faster than their native drivers. This certainly sounds counter-intuitive: the thing to take away from this is that UDI has low overhead and produces fast drivers.
“UDI will not work with my operating system design”
Maybe, but unlikely. UDI was designed to operate on anything from a single tasking, single threaded single CPU system, to a multi core, multi machine, multi threaded distributed system. You would have to be developing something massively radical to design a system in which UDI could not work
“UDI doesn’t have many drivers”
This is a chicken and egg problem and you know it. However, for any operating system which wants to use UDI, there are UDI enthusiasts (of which I am one) which would be most willing to help anyone trying to implement it – and even contribute to the work.
Remember: Every operating system supporting UDI makes it more attractive to other operating systems and driver writers. Someone must just take the plunge and support it.
“UDI means closed source drivers”
This one comes primarily from the FSF, but then much of what the FSF says I disagree with. OK, I’ll admit: You would likely get closed source drivers – but then you already do. Have you ever seen the source of ATi or nVIDIA’s graphics drivers? And, of course, most devices have open datasheets anyway – so even if the vendor didn’t open source their drivers we would be stuck.
In fact, I see very few cases where the current state of affairs have caused a driver’s source code to be released – most drivers are developed by unrelated developers, and the same benefits of delegating much of the ongoing maintenance work to the project’s volunteers would apply.
However, there is a very, very compelling reason to use UDI, which I feel outweighs this:
UDI gives us better quality systems
This applies from two points:
- Driver maintenance gets shared between bigger pools of people, increasing the overall quality of drivers
- Operating systems developers can focus more on the bits of their OS which differentiate it, since they are no longer spending as much time on maintaining drivers
UDI gives us more choice
At present, in descending order of hardware support, you have
- Windows
- Linux
- The BSDs, Solaris, etc
with enormous gulfs between them. This is constricting: It means that people are often forced to choose one because of their hardware, and denies users choice.
UDI makes closing these gulfs much, much easier, because we reduce duplication of effort.
UDI benefits everyone
Where can I get more information?
The UDI core specification can be found at projectudi.org. However, this website hasn’t been updated since 2001. You may think that this makes UDI obsolete, but you would be wrong: Software and good engineering doesn’t rust. Daily we use technologies, such as the SCSI command set and x86 and ARM processor architectures, and operating systems, which are much older. Many of these have been modified substantially, true; but the core design concepts remain mostly unchanged since their inception.
Deven Corzine said similar things about UDI as I just did a while ago.
A group of us interested in reviving UDI have setup a website at udi.io and associated mailing lists and other resources upon which to conduct the discussion with regards to taking UDI forwards. The effort is new, yes, but the discussion that has proceeded it has been going on for a year, and involved some of the specification developers.
The UDI project is dead; long live the UDI project.
