Hi, I heard about this discussion, and since I was part of the core team that developed UDI, I thought I would try to shed light on a few points. First, a brief bit of history and context:
I am no longer working for an O/S company, but at the time I worked on UDI, I had worked on many different parts of the UNIX System V kernel (VM, FS, boot, I/O, and others), both as developer and architect. I followed the "official" UNIX source base (from which all others were licensed) as its ownership (or "stewardship" as it turns out in SCO's case) moved through a series of companies including Bell Labs, USL, Novell, SCO, and then Caldera (which belatedly renamed itself SCO). I left soon after the Caldera acquisition and before the policy of sue-everything-that-moves, which I do not condone.
The UDI work started before SCO's involvement; I brought it over with the UNIX acquisition, but in the end SCO did become one of the most proactive in supporting it and actually using it in product and even producing driver-writer training materials (still available on the projectudi.org site--
http://udi.certek.com/Presentations/SCO_Forum_1999).
From the start, this was a multi-company effort, with support from over a dozen companies, both O/S and driver providers, and always at least 5 or 6 of us actively involved in the spec design. And even though many of us were representing UNIX companies, we set a strong goal early on that UDI be completely O/S-neutral and NOT be tied to traditional UNIX APIs or models. I firmly believe that we succeeded.
Unfortunately, though we did complete a great and innovative piece of technology--which is still usable and appropriate today--we couldn't get it to go any further, because the effort was primarily driven by a group of engineers and architects, and we couldn't get enough momentum on the business side. If there had been one shrewd business person truly committed to it, it probably would be commonplace today. (No, I'm not bitter.
)
So as of 2001 or so, activity on the specs, the website, the mailing lists, and general efforts to further the goals of Project UDI, petered off as we each lost momentum within our respective organizations and as each of those organizations continued to dwindle as part of the overall death of the UNIX O/S industry. But there are a number of us who, as individuals, would support any renewed efforts if they appear to be committed and productive. If new materials became available I could put them on the website.
But let's get to some specific points:
Does UDI stifle innovation or limit the ability to add features to the O/S or driver? No. In fact, it's the reverse. The UDI APIs were very carefully designed to work in a wide variety of O/S architectures: real-time, time-sharing, or virtual; server, desktop, or embedded; traditional kernels, micro-kernels, or distributed systems; single processors or highly parallel systems with or without shared memory; drivers running in kernel space, user space, on dedicated I/O processors, or over a network. All of these possibilities and more without ANY change to the driver code.
Many factors lead to this flexibility, including an asynchronous message-based API (even for resource allocation); a precisely-defined model for memory usage; O/S-driven driver instantiation, discovery, and I/O resource assignment; and, in general, hiding as much detail as possible from the driver about the O/S implementation and the underlying hardware platform. Have we covered every possible architecture? Probably not, but we've come a whole lot closer to it than any other driver API I've seen.
By narrowing the responsibility of the driver to dealing with the functions of its device and the bare minimum necessary to communicate with the surrounding environment (O/S and/or other drivers), UDI allows O/Ses to add features and make architectural changes
at any time without having to worry about changing existing drivers or driver APIs. At the same time, it allows drivers to implement and export new functional features of their devices, and to experiment with different architectures for their own devices without affecting upper software layers.
There are plenty of opportunities for uniqueness and "reasons for people to be interested in" O/Ses that happen to use UDI, even within the I/O subsystem, let alone the rest of the O/S.
I commend Brendan for what sounds like--from his comments on this thread--a pretty sophisticated O/S that uses a number of the advanced architectural techniques we envisioned when we designed UDI to be able to go well beyond the traditional UNIX kernel. Without examining it more closely, I can't say whether the UDI API and architecture 100% covers all of his driver requirements, but I suspect that it does.
Could Brendan--or any O/S provider--develop a "proprietary" driver API that's more finely tuned to their specific O/S architecture (in its current version) than a generic portable interface like UDI? Sure, and Brendan quite likely already has. BUT, in general this a challenging piece of work that is at best likely to yield only a small increment in functionality or performance over what can be achieved with UDI. (In practice, all UDI implementations so far have shown
increased performance and scalability over native drivers, even when implemented as a "wrapper" underneath the native APIs.) It also means you have to write (or port) all the drivers yourself, or convince someone else to port the drivers to your proprietary API.
You also potentially have to
change your API and possibly revise all existing drivers when you make certain changes to you internal O/S architecture (so as to maintain the "fine-tuning" to your architecture), unless you built sufficient flexibility and abstraction into the API in the first place (but then it would be a generic portable interface just like UDI) or keep the API for compatibility and then sacrifice performance or features.
We all have limited resources, whether it's a single person working on a hobby O/S, a big open-source project, or a commercial O/S. Why not spend the effort on the core features and/or architectural design elements of the O/S, rather than designing yet another driver API and porting umpteen drivers (and/or convincing h/w vendors that choose to keep their device designs proprietary to port their drivers to your O/S)? Let h/w providers work on h/w drivers, and O/S providers work on O/S internals.
Which came first, the chicken or the egg? or
Why should I implement UDI in my OS/driver when there aren't any UDI drivers/OSes out there? This was always one of our biggest challenges with the business folks, but the answer should be simple:
Someone has to go first. If more OSes support UDI, more drivers will get written (even if some of those are ports done by the early OS providers themselves), and as more drivers are available, more OSes will support it, and then you reach critical mass.
Here's my favorite:
We already have x many h/w vendors and drivers supporting our OS. If we implement UDI, and get our vendors to rewrite their drivers, then our competitors will get all those drivers for free (by also implementing UDI) and we'll lose our competitive edge. Over the years, I heard this same argument from folks at every single UNIX vendor, as well as Novell's NetWare. Of course, every one of them claimed that THEY were the leader in IHV (Independent Hardware Vendor) support, so why should they give up that lead.
Come on folks! The ONLY one who could truly make that claim in the last 15 years, and for the foreseeable future, is Microsoft. They are the only ones for whom h/w vendors automatically write drivers. They are the only ones who really do have a marketing incentive to discourage portable drivers. For every other O/S, driver support (or lack thereof) is a
negative differentiator. (In marketing terms this means that the
lack of support for a device will hurt you more, when being compared to a competitor, than support for one will
help.)
Where are all those UNIX vendors now? And NetWare; what's NetWare?
Of course, SCO didn't make it either, but then--as much as I appreciate the effort they
did put into UDI--it was probably too little, too late. Of course, they also did things that pissed off a lot of people, and were also victims of the general UNIX market downturn.
Does UDI support ALL types of drivers and hardware? Well... Yes and No. This is one area where you definitely don't get something for nothing. The answer is that the core specifications cover 95% of what you need to write a driver. They cover all the things that are common across all types of drivers: driver instantiation, resource allocation, communication between drivers or between drivers and the O/S, interrupts, priorities, and so on.
However, each type (or "class") of device (such as mass storage, serial port, Human Interface Device, etc) needs a set of specific requests and responses that reflect the particular semantics of that type of device. These are defined in what UDI calls a "metalanguage", one metalanguage for each device class.
Project UDI has so far published a small number of "add-on" specs that define metalanguages for specific device classes (Network, and SCSI), plus a few specialized metalanguages in the core specs. The USB standards group has published a USB UDI metalanguage (
http://www.usb.org/developers/devclass_docs/usbdi10.pdf)--though it's in need of some revision (for which I, personally, probably have the only complete set of notes--on paper, no less). I also have a mostly-complete HID metalanguage which has not yet been published. (Both victims of the timing of my leaving SCO.)
For other device classes, new metalanguages would have to be written. The core UDI spec provides procedures, policies, and tools for developing new metalanguages. These could be done ad hoc for specific OSes, but to get the most out of them, you would want them to be standardized and published by some related standards body or industry group, or at least a group of multiple implementors. Project UDI, having no active official resources at this time, could probably still scrounge up enough volunteers to review, "approve", and publish new driver-class specs, if the bulk of the design and writing were done by someone else and validated by at least one implementation.
Fortunately, with modern devices this is a relatively easy process, since the detailed semantics for device classes are often defined in hardware specs, such as USB. So we can take things like HID, Mass Storage, Power, and so forth, generalize them a little bit to not be USB-specific, and then simply cast them into the structure of a UDI metalanguage (for which the general rules are specified on the core spec).
Similarly, additional processor bindings (which specify binary formats and calling conventions, usually by reference to existing standards) can be published. I'll be happy to put the proposed AMD64 binding on the Project UDI site. Any given O/S, though, only needs to worry about the binary formats they choose to support. UDI allows for drivers to be distributed as source or binary, and any combination of source and/or multiple binaries can be included in a single driver package. (This is the point on which the FSF--i.e. Stallman--had the philosophical objection; UDI tried to be pragmatic, especially with respect to commercial OSes, allowing drivers to be source OR binary; the FSF wanted to
require source; we said any particular OS can choose to support only source drivers, but that wasn't purist enough for them.)
The UDI Core specs are so big, it must be too complex and costly to implement, right? Wrong. The specs are big because they go into great detail about the APIs and required behaviors, in an attempt to eliminate all ambiguities that might interfere with the complete portability of the drivers. Also, the detailed APIs are a bit repetitive (with request and response parts of most operations, with caller and callee forms of each). Once you get the feel for it, you can skim through most of it pretty quickly.
P.S. If you haven't seen Deven Corzine's 2005 editorial on this topic, I recommend it:
http://www.ties.org/deven/udi.html
More materials are available at
http://projectudi.org
