Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Thanks for this, without this I had no clue what the article was referring to.

It would be nice if there was a fairly stable kernel API (or ABI) so drivers like this didn't have to be in the kernel. Out of tree drivers are a nightmare to maintain.

I maintained some out-of-tree drivers for years at Myricom (version of myri10ge with valuable features nak'ed by netdev, MX HPC drivers). Doing this was a massive PITA. Pretty much every minor release brought with it some critical function changing the number of arguments, changing names, etc. RHEL updates were my own special version of hell, since their kernel X.Y.Z in no way resembled the upstream X.Y.Z It got so bad to support 2.6.9 through 3.x that the shim layer for the Linux driver was almost as big as the entire FreeBSD driver (where nobody cared that I implemented LRO).



This is by design. Linux doesn't want to pay the maintenance and performance costs of guaranteeing a stable in-kernel API/ABI:

https://www.kernel.org/doc/Documentation/process/stable-api-...


You can make the same argument about user space compatibility. It's extra work and may prevent some improvements, but it's nice to have.


> It would be nice if there was a fairly stable kernel API (or ABI) so drivers like this didn't have to be in the kernel.

Why? We want as many drivers as possible to be in the kernel.


because many times people want to be able to run new drivers (e.g. with new hardware support) on an LTS kernel.

lots of vendors support this, and most do it by maintaining a version of their driver that can work with a wide range of kernel versions that detect and adapt to what APIs get added/renamed/removed.


Citing being able to use an LTS kernel as the reason seems like circular logic. If every device had a mainlined driver, what would you need an LTS kernel for, rather than just always using the latest?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: