lkml.org 
[lkml]   [1997]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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
>
>


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:1.624 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site