> > I'm all for openness of device programming specs, but I think it's a
> > bit disingenous to suggest that all a company has to do to get a
> > driver written and supported is throw some documentation over the
> > wall. And it's crazy to suggest that the driver will work on every
> > platform and be supported by enterprise distros.
>
> Why is that crazy, we do that already today with the majority of drivers
> in Linux.
Well, we can disagree about the majority of drivers. My feeling is
that most of the drivers that are really used by lots of people get
support beyond just a dump of docs -- in fact often vendors are
maintaining them, eg e1000, tg3, cciss, etc., to pick some running on
the boxes I have around here.
> > Just look at the in-tree drivers: there are tons of them that don't
> > work on big-endian platforms, or have 64-bit problems, or have no SMP
> > support. And that doesn't even count drivers that are so bitrotted
> > they won't even build any more.
>
> Like Jeff said, many of these are quite old.
OK, but why isn't your army of volunteers fixing them?
> > And there are plenty of documented devices that no one cares enough
> > about to submit a driver for.
>
> Any specific examples? I have a long list of people who wish to write
> new drivers but just don't know which hardware is not yet supported.
I have a Cisco USB webcam that supposedly conforms to the "USB Video
Device Class", but nothing happens when I plug it into my Linux box.
I assume the device class is specified as part of the USB spec...
And I seem to recall there's more SATA chipset documentation than Jeff
Garzik has time to implement support for.
> > In the real world, a vendor that wants to make sure a device is
> > supported by Linux had better pay someone to write the driver and keep
> > it working. Of course, if the device is popular enough or simple
> > enough, docs are all that's needed, but in many cases no one competent
> > to write the driver is going to volunteer to do it.
>
> That's not true at all. We have a whole raft of drivers in the kernel
> that are supported only by the community (like the whole USB stack for
> example) that vendors rely on working properly.
Sure, I agree 100% that the community can deliver great drivers when
sufficient interest, documentation, and testing resources are all
available. And of course sufficient interest and testing resources
can substitute for documentation and vendor support -- cf forcedeth,
which was written with no documentation at all.
I'm disagreeing with a stronger assertion -- your original email said
that if a vendor just dumps out hardware documentation and donates a
few devices, then that vendor will definitely get a driver that will
be picked up by enterprise distros and run on every Linux platform.
And that just isn't true, or at least experience shows it hasn't been
true until now.
- R.
-
