UDI and I2O

Project UDI (Uniform Driver Interface), an open multi-vendor working group formed in 1994 for the purpose of creating an OS-neutral device driver standard, applauds the I2O SIG for bringing the results of their work to the public. Project UDI shares with the I2O SIG a desire to create and promote standardized OS-neutral interfaces for device drivers. By doing so, both groups hope to facilitate rapid and cost-effective deployment of new technologies by hardware device and adapter vendors as well as by platform and operating system vendors.

Both Project UDI and members of the I2O SIG have been working on advanced I/O architectures and the driver problem, but have each focused on different aspects. The I2O team has focused on intelligent I/O architectures and issues associated with running drivers on I/O processors, while Project UDI has focused on allowing a single driver to work across a wide range of platform and OS architectures.

The I2O SIG has several areas to cover, besides just the device driver interface. Motivated by a desire to promote I/O processor (IOP) architectures, I2O must also address:

  • IOP hardware architecture
  • Byte transport protocols between host and I/O processors
  • Transport driver interfaces
  • Message protocol over this transport
  • IOP initialization and configuration
  • There are many issues and details to be worked out in the above areas alone. Device driver interfaces, which will affect every IHV, deserve careful and focused attention.

    Both the UDI and I2O efforts (and the IHV community) would therefore benefit from exploiting the inherent synergy between the two groups, and working jointly toward a truly universal device driver standard.

    Combining UDI and I2O

    There are a number of ways in which pieces of I2O technology could be combined with UDI. Here are some examples. In all cases, the I2O hardware and byte transport protocols would be used.

    Model 1 ("I2O Fabric"):

    [ UDI on host => I2O MSG => IOP => I2O HDMs ]

    In this model, UDI forms the driver interface and infrastructure for drivers running on host CPUs (along with OS-specific legacy drivers); the I2O message protocol is used to communicate with the IOP(s), and everything in the IOP is I2O. The host system treats I2O as just another heterogeneous fabric or interconnect, like Fibre Channel.

    For each I2O device class, a UDI "mapper" would be written. Each such mapper would appear as a UDI device driver for the appropriate device type, and would convert UDI requests into I2O messages, then send them to an I2OMSG driver (probably also a UDI-compliant driver), which would send the messages to the appropriate IOP(s). These UDI mappers, as with all UDI drivers, would be completely portable. Thus any host OS which supported UDI would be able to support I2O devices with no additional work.

    Model 2 ("Universal Drivers"):

    [ UDI on host => I2O MSG => IOP => UDI drivers ]

    An unfortunate property of Model 1 is that if the same card can be plugged in (e.g. to a PCI bus) either on an IOP local bus or directly on a host I/O bus, then two different drivers are needed for the same device, one UDI driver for the host, and one I2O HDM driver for the IOP. To fix this, we note that UDI supports location transparency. With a UDI environment implementation on the IOP, the same UDI driver which ran on the host CPU(s) could be simply recompiled, and would then run on the IOP(s).

    Therefore we modify Model 1, and replace (or augment) the I2O driver environment on the IOP(s) with a UDI environment, using UDI drivers on the IOP as well as the host. The I2O specification continues to be used for hardware design, for message passing between host and IOP, and for IOP initialization. Hopefully, in this model, the I2O specification changes to refer to the UDI specification for its driver interface model.

    Comparison of Driver Models

    The current draft UDI and I2O driver interface specifications share some aspects in common, but also have some significant differences.


    To find out more about I2O, visit the I2O SIG Web Site.