
Ask HN: Why no stable binary kernel interface for drivers? - 708145_
Linux does not have a stable binary kernel interface for drivers. This enforces either that all the drivers must be in the kernel source tree or that drivers become broken with kernel updates.<p>I don&#x27;t want to have a political debate here about free software. But I can see ideological reasons for how Linux try to force hardware manufacturers to share the code for their drivers.<p>The (proprietary) driver issue is a big pain for people who want to use Linux for desktop as a workstation e.g. development. I would say that it is the biggest obstacle for adaption of Linux desktop.<p>Why couldn&#x27;t we have long term supported kernels with decoupled drivers?<p>Discussion: http:&#x2F;&#x2F;lkml.iu.edu&#x2F;hypermail&#x2F;linux&#x2F;kernel&#x2F;1604.0&#x2F;00998.html
======
rtb
This is addressed in the docs, at "stable_api_nonsense.txt":
[https://github.com/torvalds/linux/blob/master/Documentation/...](https://github.com/torvalds/linux/blob/master/Documentation/process/stable-
api-nonsense.rst)

(You might disagree with that doc, but if so you should address its arguments
directly.)

------
microcolonel
Maintaining the drivers together with the rest of the system allows subsystem
maintainers to make broad improvements to the functioning of drivers, and
encourages vendors to upstream them as free software.

If you want a stable kernel driver ABI, then you're going to have to maintain
your own wrapper which will retain all of the anachronisms that have been
excised from the upstream kernel.

You are perfectly at liberty to do this for yourself, just don't expect kernel
maintainers to willingly make their own lives harder, reduce the quality of
running kernels, and reduce the enthusiasm for releasing and upstreaming high
quality drivers.

As an alternative to a stable ABI, you can just go with a single LTS release,
and you can expect binary compatibility on the order of four years.

~~~
708145_
But if vendors does not want to upstream them as free software, then we have a
problem and an issue with the non stable ABI solution. The end user does not
care if the driver is free software, they just want their machines to work. I
guess this is an issue for Google too, for their Linux fork Android.

Of course everyone has the liberty to write a wrapper, but that is just silly.

If Windows can have a stable ABI, why can't Linux have it too? Why would it
need to "reduce the quality of running kernels"?

~~~
catdog
> The end user does not care if the driver is free software, they just want
> their machines to work.

Upstreaming the code also means quality control. Linus and his subsystem
maintainers by far do not merge everything people throw at them. Users also
gain out of the box support for their Hardware if the driver is in the kernel.
Also a lot of people using and developing Linux or the surroundings care about
(at least some aspects of) free Software.

> Why would it need to "reduce the quality of running kernels"?

Because possibly (mostly, HW manufacturers in general are not exactly known
for the quality of their software) low quality code becomes part of the
kernel, Linux is a monolith.

> If Windows can have a stable ABI, why can't Linux have it too?

I think not providing a stable API/ABI is a major reason why Linux is able to
move so fast. If you have to make sure your change does not break this 5+ year
old driver you can't do major architectural changes that easily. The kernel
developers would then need write the equivalent of such a "silly" wrapper.

> I guess this is an issue for Google too, for their Linux fork Android.

Google apparently likes doing this, e.g. they also maintain a fork of openssl
to make some minor changes for their needs.

~~~
euyyn
Google's fork of OpenSSL, BoringSSL, is very far from "some minor changes".
[https://boringssl.googlesource.com/boringssl/](https://boringssl.googlesource.com/boringssl/)

------
Someone
As
[http://lkml.iu.edu/hypermail/linux/kernel/1604.0/03993.html](http://lkml.iu.edu/hypermail/linux/kernel/1604.0/03993.html)
states, you can get binary stability for in the order of five years from the
likes of Red Hat and SuSe.

I don't know where you can get binary stability for decades, but it wouldn't
surprise me if some military applications guaranteed that.

Since there's nothing stopping suppliers from selling it, there apparently
isn't that much demand for it.

~~~
708145_
> As
> [http://lkml.iu.edu/hypermail/linux/kernel/1604.0/03993.html](http://lkml.iu.edu/hypermail/linux/kernel/1604.0/03993.html)
> states, you can get binary stability for in the order of five years from the
> likes of Red Hat and SuSe.

Yes but why can't the kernel provide a stable interface? The
stable_api_nonsense.txt is just nonsense for me.

~~~
avar
Because the kernel developers aren't interested in assuming the maintenance
burden of maintaining (possibly many incompatible and versioned) interfaces
purely for the benefit of users who maintain out of tree drivers.

~~~
mixmastamyk
I'm surprised driver interfaces are still changing so frequently. Ten years
ago perhaps, but they're not largely sorted today twenty five years+ after
Linux debut?

~~~
planteen
There have been general architecture changes. Look at DRM as a better way to
do rendering versus the old Unix way, for example.

~~~
mixmastamyk
Sure, but isn't that ten years old already? It's not like these big changes
come every month.

------
mixmastamyk
I use a Ubuntu desktop daily as a development workstation and have for a
decade at least. Never really had a problem, though it slows down Virtual Box
installation once or twice a year. _shrugs_

~~~
catdog
They should really mainline their stuff (or better build onto kvm)… On the
other hand it's pleasantly surprising by itself that Oracle did not kill the
project.

------
catdog
> The (proprietary) driver issue is a big pain for people who want to use
> Linux for desktop as a workstation e.g. development. I would say that it is
> the biggest obstacle for adaption of Linux desktop.

Simply don't buy Nvidia. Apart from that there shouldn't be a lot of hardware
requiring blobs on the desktop.

