> All that is needed is some kind of specification that describes how your
> device works, or the email address of an engineer that is willing to
> answer questions every once in a while. A few sample devices might be
> good to have so that debugging doesn't have to be done by email, but if
> necessary, that can be done.
> This driver will work with all[1] of the different
> CPU types supported by Linux, the largest number of CPU types supported
> by any operating system ever before in the history of computing.
> As for support, the driver will be supported through email by the
> original developers, when they can help out, and by the "enterprise"
> Linux distributors as part of their service agreements with their
> customers.
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.
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. And there are plenty of documented
devices that no one cares enough about to submit a driver 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.
- R.
-
