Re: The i2o Bus: A Conspiracy Against Free Software? (fwd)
Systemkennung Linux (linux@mailhost.uni-koblenz.de)
Sat, 19 Jul 1997 16:22:09 +0200 (MET DST)
>
> On Fri, 18 Jul 1997, Christopher Blizzard wrote:
> > :Also, wouldn't this be anti-competitive practice? They're preventing
> > :OS vendors who want to ship source from being able to support the
> > :hardware needed to retain market share. Maybe one of them will sue,
> > :be it RedHat, Caldera, BSDI or whoever...
> > :
> > :The other option would be for a company (or individual) to sign the
> > :NDA, develop the driver and make it available as a binary only kernel
> > :module. Not ideal, I know, but it would at least be one solution.
> > :Wasn't something like this done for AFS support?
> >
> > There are a couple of examples of this including Caldera's binary module
> > for Novell access similar to ncpfs. There was also a serial port driver
> > that Alan Cox mentioned once which I belive was distributed as assembly
> > that didn't work very well.
>
>
> One even more important difference is that all those binary only modules
> that we currently have are for one filesystem or one specific device
> or some other very specific aspect.
>
> The I2O Group is trying to take over all IO subsystems. Now what are we
> going to do without display, networking and mass storage devices?
> A kernel without all of those devices is not exactly very usefull.
>
> Pretty much all manufacturers in the SCSI sector at least are working
> frantically on their move to I2O. For them it wouldn't make much sense
> maintaining multiple different interfaces, it only creates additional
> costs for them. And why should they ? Microsoft and other M$ controlled
> companies like SCO will provide I2O subsystems on time and together they
> controll most of the market anyway. The loss in sales to users of Linux,
> Free(and other)BSD(s), is negectible in comparison to the amount of money
> hardware manufacturers save by having to develop only one driver per
> device instead of dozends.
>
> It shouldn't astonish people if they see the I2O API fitting seamlessly
> into the NT architecture.
Trying to look at things from the positve side - one of the I2O design
goals is to reduce the effort spent into drivers. The free software
community is much more limited in what we can invest into drivers. If
we can hold of the I2O specs it might well be an advantage for us. And
I have no doubt that we will support I2O even if the specs should be
ultrasecret - burn before read. Aside the switch to I2O will take a
long time. If I look at highlevel interfaces like those in DPT SCSI
hostadapters then I suppose those products as well as many others will
need significant restructuring and time to support I2O optimally.
Time we can use.
Ralf