lkml.org 
[lkml]   [1997]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: The i2o Bus: A Conspiracy Against Free Software? (fwd)

What if the OS&Drivers have the responceibility of programming the I2O
chip? also, does the I2O spec tie you into using the i960? Assuming
someone clean roomed the I2O spec, could I produce a MB that used a TI-C6
DSP, A sharc, or a 68K coldfire? and have any OS look on it the same as
the i960 in a Intel MB?

What I2O boils down to is offloading the host CPU, it's a
device-coprocessor. Many devices already have their own processors, and
since PCI devices can access the entire memory space, I dont see any
reason why a combination of good hardware and drivers couldn't accomplish
the same thing.. (See SCSI cards that do mailboxing, like my BT-948 with
it's spiffy 25mhz 80186) So, this seems to me as a crutch which limits
choice and flexibility.

I think Intel figured out they made a mistake making PCI largly platform
independant... Would you have believed it in the 80's if someone told you
that you could use the same videocard in a mac, a dec supercomputer, and a
Pc? Now, Intel regrets it and they are trying to fix it.. Would someone
be so kind as to create an anti-I2O mailing list and subscribe me?

Thanks,
Gregory Maxwell

On Fri, 18 Jul 1997, Benjamin Saller Bender wrote:

> Dan Hollis <mailto:goemon@sasami.anime.net> writes:
> >Someone should make a comprehensive web page about why I2O is wrong, why
> >the NDA is wrong, the real reason behind the NDA, why I2O is nothing new,
> >compare I2O to MCA (that should scare a lot of management types), etc.
> >
> As I understand it, and I've only glanced at the design overview, I2O
> is designed so that hardware vendors can write drivers to a layer falling
> between the OS and the devices. This layer is controlled by a i960 running
> something along the lines of vxWorks. The OS (linux in this case) only needs
> to be able to talk to the interface exported by the i960. We don't need the
> detailed specs of the underlying communications between the i960 and the
> device being controlled.
> So you say, how do we obtain the protocol to talk to the generic
> communications layer? Here is my (maybe naive) thought on the matter. If we
> don't get it from the hardware vendors there sales suffer. Thats the bottom
> line. Linux users and the other free OS are no longer totally ignorable from
> the view of the all powerful dollar. It is in the best interest of the
> hardware vendors to make there drivers work on a number of OS, even if M$ gets
> a little peeved. The cost of driver development for hardware vendors drops if
> they only need to write it once for it to work on 95/98/NT, OS2, Linux, etc.
> If this is the way of things they will have to make the spec to talk to said
> drivers public.
>



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