On 09/27/11 00:05, Grant Edwards wrote: >> >> Contribute your drivers upstream. When the devs change an API, they'll >> update your code for you. > > That sounds good, but in practice it doesn't work. > > 1) The kernel developers don't support any existing customers. Bugs > are only fixed for customers who are willing to run the next > kernel verison. I've got customers that are still running 2.4 > kernels. 2.6.18 is still widely used. Will the kernel developers > add new features, support for new hardware, or fix bugs for those > customers. Not a chance.
If your users don't upgrade their kernel, then the API doesn't change, and there's no problem for these customers, right? > 2) The kernel developers only make sure that drivers compile. They > don't have the hardware or knowlege required to actually test > them. One of our drivers _is_ in the kernel. Sure, it builds, > but AFAIK, it hasn't actually worked for at least 10 years. > > Trying to maintain two drivers (one in-kernel and one out-of-kernel) > just creates twice as much work for no gain. > So (assuming the devs do break your stuff occasionally) you have to test and possibly fix at least one driver whenever the API changes. I see a few options: 1) Test/fix one driver, in-kernel (less work) 2) Test/fix one driver, out-of-kernel (more work) 3) Test/fix two drivers, one in- and one out-of-kernel (most work) In any case, even if I'm wrong about the amount of work involved, it would be nicer for your customers if they didn't have to ask your permission to upgrade the kernel.
