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