Messages in this thread | | | Date | Thu, 8 May 1997 16:24:29 -0700 (PDT) | From | Dean Gaudet <> | Subject | Re: i2o support |
| |
It seems to me to be just another iteration in what the industry has done time and time again. At time A, all I/O is handled by the main CPU, but then high speed CPUs are expensive, and it's a "win" to move the I/O to a specialized processor. Then at time B CPU speeds increase/become less expensive, and someone discovers that it's faster to move that processing back into the main processor. Then the cycle repeats itself... for various definitions of "expensive", and "fast".
For network cards I would certainly not want to have another processor involved (it'd mess up quake of course). For disk subsystems I really couldn't care either way (although I really liked hacking the cpu on my commodore disk drives ;). For video anything but dedicated buses isn't going to get the speed/latency requirements necessary these days...
Where I2O might have a real nice edge is that manufactures write drivers once, and it works on all OSs (stop laughing). But we've heard that before... prep/chrp (stop laughing!).
Dean
On Thu, 8 May 1997, Alan Cox wrote:
> > >so we ought to campain the I2O group to release the spec. See > > >http://www.i2osig.com for info. Their address and phone is: > > > > Any ideas on how hard it would be to reverse engineer this. It seems to me > > that this could be a great I/O system for an Intel based systems. > > Im very very dubious. it seems to be based on sending all the I/O requests > to an offboard processor. The word LATENCY comes to mind. > > Alan > >
| |