UDI Advantages Beyond Driver Portability
        ========================================

We've all heard the UDI 100% portability story, which is a great
thing, but often perceived to be an insufficient motivation by itself.
Here's a list of other advantages to the UDI driver model as advanced
driver technology, regardless of the portability.

1. Performance of UDI drivers is currently comparable to or better than
legacy drivers in most cases (as measured on UnixWare 7 with DDI
drivers), but we have not even begun to scratch the surface of UDI's
potential for increased performance. As proof of the UDI architecture's
performance-by-design, the current parity with legacy drivers is
achieved even though the UDI implementation is currently LAYERED ON TOP
of the DDI implementation; therefore, the UDI implementation is already
faster by at least the cost of the layering, so we can gain even more
performance simply by integrating UDI more tightly with the kernel and
bypassing layers.

2. Even more than baseline performance, the UDI synchronization model
was designed for increased MP scalability. Even with the current fairly
simplistic implementation, a significant scalability improvement over
legacy drivers has been measured.

3. The UDI programming model facilitates development of more reliable
drivers by reducing or eliminating several categories of potential bugs
and performance issues (deadlocks, missing locks, excessive mutex
contention, resource leaks, etc.). Drivers do not have to worry at all
about MP locking or threads; nor do they have to implement their own
private resource allocation/management strategies. (On the flip side,
there is a learning curve to get into the UDI programming model the
first time you do it, but once you do, it's harder to make mistakes.)

4. The UDI driver APIs allow the OS to easily validate driver behavior
and catch common mistakes, increasing the ease and effectiveness of
driver debugging and certification.

5. Most new I/O technologies are inherently suited to layering/stacking
(MPIO over SCSI; USB keyboard over HID over USB protocol stack over USB
Host Controller; Infiniband Target Channel over Infiniband protocol
over Infiniband HCA, ...) It has often been a challenge in the past
adding layered driver models (e.g. MPIO) into legacy models. UDI makes
this easy. Layering support is built-in and fundamental to UDI.

6. UDI facilitates I2O support or any other form of offloading I/O
processing onto dedicated I/O CPUs/hardware, including certain modes of
operation on Infiniband.

7. UDI could facilitate SAN support, in terms of creation, configuration,
management, and error recovery policy.

8. UDI is much more flexible and extensible than other driver models.
It's much easier to add support for a completely new kind of device onto
an existing UDI framework than it would be to add on top of many
legacy models.

9. UDI allows driver messages to be localized. Traditional driver models
only support messages in one language.

10. UDI inherently supports hot-plug, making it easier to support
hot-plug PCI, USB, or other pluggable technologies in the OS.


        Opportunities for Value-Add using UDI
        =====================================

While allowing for completely portable drivers, UDI at the same time
allows for many opportunities for specific OS products to add value
"behind the scenes", without any changes to the drivers. Here are some
examples:

1. "Driver Isolation", aka "Region Kill". This allows for execution of
drivers in a protected address space, which can prevent a misbehaving
driver from panicking the system or compromising the integrity of the
kernel. The kernel can terminate and re-start a driver without bringing
down the system. (Possibly without even losing any data or connections.)
This would be great for debugging or for high-reliability RAS systems.
(This could be implemented in such a way that you could turn it on or
off for individual drivers, or even driver instances.)

2. User-mode drivers. Very much like Driver Isolation, but puts the
separate address space in user mode. This would allow you to use
traditional user-mode application debuggers to debug drivers. We already
do this to some extent in the "posix environment", but it's somewhat
limited (no DMA or interrupts, and no way to plumb the driver
"underneath" in-kernel subsystems like network stacks or filesystems).

3. Offload I/O workload to specialized I/O processors (IOPs). UDI
drivers work the same whether they're running on a primary host CPU or
on an IOP.