Re: I2O article
>On Tue, 26 Aug 1997, Bruce Perens wrote:
>> As far as I can tell, they have blown any non-disclosure case they ever
>> might have had. Unless they make _tremendous_ changes in their standard,
>> we now know all of what we need to know to write device drivers for it.
>Hm, there may be one problem, I do not know the details of I2O, but if it
>is required to run a process on the I2O controller itself then we still
>may be in big trouble.
"You" (the device driver author) should not need to develoop any code that
runs directly on the IOP. The IOP normally comes with it own firmware,
from which it should boot.
There will be/are two types of IOPs:
1. The general purpose IOPs that we probably be all i960 based
and for which you can develop additional driver modules that are
beeing loaded at runtime.
2. Specialized IOPs that might or might not be i960s and which you can
find for example on the next generation of SCSI controllers.
For the second, you don't need to develop a lowlevel driver module, you
just need a general driver for this "class of service" that can
communicate with all IOPs. That means we have in the SCSI case we'd only
the equivalent of the highlevel code (sd, sr, sg, st) and a less
complicated midlevel. Most of the intelligence will reside in the IOP,
which simplifies error handling dramatically for example. (If the IOP says
the command is dead, it is dead. End of discussion. It already did all
that is necessary to fix problems)
>I thought the idea behind I2O was to not require
>this, but there may be a large performance gain if it is done (??)
Yes, it is. I2O is in a more general and complicated way of what
DPT has been doing since about 1985 or 84 and IBM has been doing this
since about 1965 with the mainframe IO channels.
DPT is one of the first companies that have actual I2O hardware that is
beeing shipped to developers at the moment. I expect to get a controller
from them in the not too far future so that I can take a closer look.
They definitely want to help the Linux comunity to get I2O support into
the kernel and have setup a (not yet publically announced) mailinglist to
help coordinate the efforts. The list is the majordomo list
"The woods are lovely, dark and deep. But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to email@example.com .