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:
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.
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.
[ TO BE SUPPLIED ]