03.15
In the past I never really cared that Linux didn’t have stable kernel driver APIs, actually I even liked it, as the lack of stable APIs generally makes development easier, and things can be fixed structurally often by changing the API.
However, recently I’ve begun to feel the pain of changing driver APIs, because if a driver is broken in a certain kernel revision, the only option (if you’re not a kernel hacker) is to upgrade to a newer or older kernel. Which often isn’t desirable. A good example would be the -stable kernel 2.6.27.x which is a great effort to stabilize a vanilla upstream kernel for true production use, however to prevent regressions they have strict rules about what can go in, and what can’t. Currently in 2.6.27.x the Broadcom NetXtreme II driver (bnx2) is broken, and there a good chance a fix can’t be allowed into -stable.
The above is only really an issue because there are no stable APIs, if there were stable APIs, I could have taken Broadcom’s officially released bnx2 and used that, or I could have ripped the source files from 2.6.29 and rebuilt using that. It’s not that would have been a garantueed fix, but it would have given me options…
As far as I know, Linux upstream policy is that the vanilla kernels are not really intended for production purposes. They are to be seen as raw ore to be refined by the distributions makers. In case of RedHat (Enterprise Linux) or SuSE (Linux Enterprise Server) this works well, the vendors stabilize the kernels, and actually provide a stable API for vendors to build on. However for smaller distributions this can be an issue, since not all project have enough (or at all) kernel hackers to make this happen. So effectively you’re stuck with RHEL and SLES if you really want stable APIs. And that doesn’t put a smile on my face, especially since the RHEL kernel sources scared the living daylights out of me.
The good thing is that mostly drivers just work, and you don’t really care whether the driver APIs are stable or not. But every once in a while you get hit with a driver bug, which would have been a lot easier to resolve if drivers could be easily upgraded out of tree (and thus requiring a more or less stable kernel driver APIs).
Another important note is, that I was talking about APIs, which are source code level interfaces between different parts of the kernel. I was not talking about ABIs, which are binary level interfaces between different parts of the kernel. A stable ABI has no place in open source. Vendors which are unwilling to open source their drivers can go screw themselves (yes, nVidia that means you)!
