> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
