Thanks for pointing out the links on UDI. What are the implications for I2O and WIND? No impact.
UDI approaches the incredibly complex and incompatible device driver problem in a laudable but straight-forward way of trying to standardize all the intricate aspects of developing drivers. One wonders why this work is being done in the mid-1990s rather than in the mid-1980s.
Meanwhile, I2O has leap-frogged over the entire problem by taking a much more aggressive approach. I2O off-loads I/O and standardizes the driver interface.
Now, here is the rub. The UDI partners are mainly Unix companies, with Intel and Microsoft notably absent. I2O is the brainchild of Intel, and is the total solution championed by Intel and Microsoft, carrying along Unix representation in SCO, Compaq, HP, DEC and now even Sun. In fact, most of the UDI participants are members of the I2O-SIG. Further, it is telling that the project leader of the UDI Project takes great pains to explain how I2O could benefit from UDI, but the I2O-SIG makes no mention of UDI (as far as I can tell).
In the final analysis any standards approach will succeed only if critical mass is reached in the market place. In my mind, I2O is developing that mass extremely rapidly, and will become standard. As to whether I2O ends up utilizing UDI, I can't comment, except to wonder about UDIs apparent lack of critical mass.
By the way, note that the referenced article by the UDI Project Chairman, Kevin Quick, is riddled with defensive statements about UDI and downright misstatements about I2O. Strange remarks from someone obviously trying to offer an olive branch to the I2O-SIG. Examples:
>UDI is a truly open standards-development effort; I2O is costly and
>restricts the involvement in the standards development and approval
>process to a limited number of participants.
I2O-SIG does this to prevent developers from developing proprietary extensions to I2O, and thereby sabotaging the openness of the I2O standard.
>UDI will work for nearly any architecture, whereas I2O is limited to
>Intel 960-based environments (and presumably Intel-based host systems)
Absolutely false, as indicated by the recent DEC announcement. The wonder is why Kevin made this statement, since I2O has always been presented as an open standard and more than Intel.
>UDI will be able to support any bus; it's not clear that I2O will be able to
>provide support beyond the PCI bus.
No reason in principle I2O cannot be extended to other buses; albeit the PCI bus naturally supports powerful functions useful to I2O. The I2O is not tied to the PCI bus.
>UDI does not specifically include, nor does it preclude the ability to off-load processing.
Kevin should know, but he is missing the point. Off-load processing is important, not just to off-load processing (which is not new), but to enable peer-to-peer I/O processing of rich data types and clustering. The fact that UDI doesn't do something, but could, is not the same as doing it.
I2O is far more than just a standardized I/O driver. It is far more than just off-loaded I/O. I2O is the enabling technology for completely standardizing efficient I/O processing among all sorts of devices with minimal interference with normal CPU processing. I can provide true plug and play across all platforms. If it reaches critical mass, it will revolutionize I/O processing and become ubiquitous. Kevin senses correctly that the best thing the UDI Project can do is to join them since they can't beat them.
Allen |
