Uniform Driver Interface: Difference between revisions

From OSDev.wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Content added Content deleted
m (This isn't a notepad :))
m (Add more links)
Line 21: Line 21:
* [http://www.projectudi.org/ Official website]
* [http://www.projectudi.org/ Official website]
* [http://projectudi.sf.net/ Reference implementation]
* [http://projectudi.sf.net/ Reference implementation]
* [http://www.ties.org/deven/udi.html Deven Corzine's editorial]
* [http://osr600doc.sco.com/en/UDI_dwg/CONTENTS.html UDI Driver Writer's Guide]

Revision as of 13:19, 7 December 2009

This page is a stub.
You can help the wiki by accurately adding more contents to it.

UDI stands for "Uniform Driver Interface". It is the specification of a framework and driver API / ABI that enables different operating systems (implementing the UDI framework) to use the same drivers. Conceived by several industry big players, it has fallen somewhat dormant, despite being functional and delivering on its promise.

UDI drivers are binary compatible across all UDI-implementing operating systems running on the same CPU family. They are also source compatible across all UDI-implementing operating systems. This means, a driver only has to be developed once.

While Microsoft Windows gets all the hardware drivers they want, and GNU discourages UDI for philosophical reasons, its advantages for hobbyist OS developers are obvious.

Why UDI?

UDI has several advantages over other existing driver interface which motivated us to choose this interface above all others:

  • Portability, which was mentioned in the above section, is perhaps the primary concern for which UDI was developed in the first place. All we can hope for is that enough operating systems will embrace the model so we can actually take advantage of it.
  • Performance is comparable or better than that of legacy drivers. Let's face it, performance is always important. UDI features a non-blocking model, besides the blocking one, a synchronization model for increased MP scalability and much more. UDI drivers have proven themselves over DDI drivers (and others).
  • Compatibility has also been taken into account. UDI environments can be implemented regardless of the OS architecture (monolithic kernel vs. microkernel, POSIX vs. non-POSIX, etc.) with no extra overhead for any exotic design one might think of.
  • Stability is usually overlooked by the design and falls back to the implementation phase. UDI tries to eliminate some categories of potential bugs, such as (but not limited to) resource leaks and deadlocks.
  • Flexibility is another thing UDI has been designed mind with: not only in the way the specification was concieved (i.e., to be extensible), but also in the sense that it permits system programmers to apply techniques such as driver isolation, shadow drivers, etc. if they see fit to do so.

External Links