Uniform Driver Interface: Difference between revisions
Jump to navigation
Jump to search
| [unchecked revision] | [unchecked revision] |
Content deleted Content added
mNo edit summary |
m Toned down the "Sales Pitch" and made the article more honest and down to earth. |
||
| Line 5: | Line 5: | ||
[[Image:Udi_color_330x220.jpg|thumb|alt=Logo|The official Project UDI logo]] |
[[Image:Udi_color_330x220.jpg|thumb|alt=Logo|The official Project UDI logo]] |
||
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 |
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 large industry corporations, it has fallen dormant, despite being functional and delivering on its promise. |
||
UDI drivers are binary compatible across all UDI- |
UDI drivers are binary compatible across all UDI-compliant 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 [http://www.gnu.org/philosophy/udi.html philosophical reasons], its advantages for hobbyist OS developers are obvious. |
While Microsoft Windows gets all the hardware drivers they want, and GNU discourages UDI for [http://www.gnu.org/philosophy/udi.html philosophical reasons], its advantages for hobbyist OS developers are obvious. |
||
| Line 13: | Line 13: | ||
==Why UDI?== |
==Why UDI?== |
||
The Uniform Driver Interface would, should it be widely adopted, provide a common driver framework for implementation across kernels and platforms, enabling drivers to be provided without respect to the target kernel, and to a large extent, the target hardware platform. UDI has several projected advantages over existing driver interfaces which may motivate the reader to adopt it: |
|||
UDI has several advantages over other existing driver interfaces which motivates developers to choose it above all others: |
|||
===Advantages=== |
|||
* Portability (both cross-OS and cross-platform), 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. |
* Portability (both cross-OS and cross-platform), 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). |
* 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). |
||
| Line 20: | Line 21: | ||
* 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. |
* 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 conceived (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. |
* Flexibility is another thing UDI has been designed mind with: not only in the way the specification was conceived (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. |
||
===Disadvantages=== |
|||
* Moderately complex, and it will generally take a while to understand the specification. |
|||
* It cannot simply be ported to immature kernels. A kernel must have a certain minimum level of maturity to reasonably attempt to become UDI compliant. |
|||
* Not at all viable for "casual" projects: requires a significant amount of knowledge and prior work. |
|||
==Description== |
==Description== |
||