Uniform Driver Interface: Difference between revisions

Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Content added Content deleted
VisualWikitext
m (Toned down the "Sales Pitch" and made the article more honest and down to earth.)
(More toning down of the hyperbole.)
Line 17: Line 17:
===Advantages===
===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 for a native implementation. For environments where performance is critical, UDI does not inhibit service quality. UDI is explicitly designed to be non-blocking and lockless, featuring a synchronization model for increased MP scalability without locking and many other high-scalability focused features.
* Compatibility has also been taken into account. UDI environments can be implemented regardless of the OS architecture ([[Monolithic Kernel|monolithic kernel]] vs. [[microkernel]], POSIX vs. non-POSIX, etc.) with no extra overhead for any exotic design one might think of.
* UDI can integrate seamlessly into existing kernel environments regardless of the OS architecture ([[Monolithic Kernel|monolithic kernel]] vs. [[microkernel]], POSIX vs. non-POSIX, etc.) with little or no extra performance overhead.
* 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.
* Reliability and stability have been explicitly provided for by the design. UDI tries to eliminate some categories of potential bugs, such as (but not limited to) resource leaks and deadlocks (all interfaces can potentially be implemented without any locking at all).
* 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.
* The interface is fully asynchronous, in every respect; high scaling systems are becoming increasingly predominant and asynchronicity is slowly becoming an "expected" feature for modern kernels. UDI moves ahead of the herd to enable a compliant kernel to slowly adopt asynchronous interfaces without having to do major redesign later on.


===Disadvantages===
===Disadvantages===
Retrieved from "https://osdev.wiki/wiki/Uniform_Driver_Interface"