Ask HN: Why no stable binary kernel interface for drivers?
19 comments
This is addressed in the docs, at "stable_api_nonsense.txt":
https://github.com/torvalds/linux/blob/master/Documentation/...
(You might disagree with that doc, but if so you should address its arguments directly.)
(You might disagree with that doc, but if so you should address its arguments directly.)
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.
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.
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"?
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"?
I guess this is an issue for Google too, for their Linux fork Android.
Probably not a good example to use Google for this. Google has shown time and time again that they are culturally incapable of developing open source software if any other stakeholders have the power to say "No" to Google. And that's just for the projects developed in open, most of their "open source" is dropping code dumps for legal or strategic reasons rather than collaboration.
I'm not trying to make that sound like a complaint. They have the weight to throw around to enable their uncompromising and secretive approach to opensource. Them's just the breaks.
Probably not a good example to use Google for this. Google has shown time and time again that they are culturally incapable of developing open source software if any other stakeholders have the power to say "No" to Google. And that's just for the projects developed in open, most of their "open source" is dropping code dumps for legal or strategic reasons rather than collaboration.
I'm not trying to make that sound like a complaint. They have the weight to throw around to enable their uncompromising and secretive approach to opensource. Them's just the breaks.
> 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.
You're saying this as though the end user experience is separate from improvements to the performance and semantics of the driver ABI.
Also, on Android all of the (kernel space) drivers are free software; it's just that they're so crappy usually that they can not be upstreamed. They don't hook into much of the infrastructure in the kernel on account of ignorance, so they could easily push updated kernel module binaries, ABI compatibility does not affect that problem.
Android's kernel is not a fork of Linux, it's a LTS tree with some configuration changes, and a couple of modules (most of which have been upstreamed by now).
> 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"?
Windows doesn't have a stable driver ABI, they break driver ABIs pretty drastically every once in a while. Longhorn (later yielding Windows Vista) was the last straw, they couldn't build a good quality operating system with the same driver ABI.
Furthermore, drivers from Vista often do not work with 7, 8, or especially 10. You can get the exact same sort of stable driver ABI by distributing for a specific distribution release or long term kernel tree.
You're saying this as though the end user experience is separate from improvements to the performance and semantics of the driver ABI.
Also, on Android all of the (kernel space) drivers are free software; it's just that they're so crappy usually that they can not be upstreamed. They don't hook into much of the infrastructure in the kernel on account of ignorance, so they could easily push updated kernel module binaries, ABI compatibility does not affect that problem.
Android's kernel is not a fork of Linux, it's a LTS tree with some configuration changes, and a couple of modules (most of which have been upstreamed by now).
> 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"?
Windows doesn't have a stable driver ABI, they break driver ABIs pretty drastically every once in a while. Longhorn (later yielding Windows Vista) was the last straw, they couldn't build a good quality operating system with the same driver ABI.
Furthermore, drivers from Vista often do not work with 7, 8, or especially 10. You can get the exact same sort of stable driver ABI by distributing for a specific distribution release or long term kernel tree.
> 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.
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.
Google's fork of OpenSSL, BoringSSL, is very far from "some minor changes". https://boringssl.googlesource.com/boringssl/
As 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.
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.
Stable API or not, every time there is a new NVIDIA driver, my Win10 boxes work and my Fedora/Ubuntu ones break. I doubt Microsoft is asking NVIDIA to keep their driver inside Microsoft repositories.
> Stable API or not, every time there is a new NVIDIA driver, my Win10 boxes work and my Fedora/Ubuntu ones break
Use a distro that ships the Nvidia driver in its repos or a repository that builds for your distro's kernel specifically.
Use a distro that ships the Nvidia driver in its repos or a repository that builds for your distro's kernel specifically.
> As 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.
Yes but why can't the kernel provide a stable interface? The stable_api_nonsense.txt is just nonsense for me.
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.
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?
There have been general architecture changes. Look at DRM as a better way to do rendering versus the old Unix way, for example.
Sure, but isn't that ten years old already? It's not like these big changes come every month.
Not "can't," but "won't." It's not considered worth the effort; the technical benefits are too great when doing it the current way. The political side effects are a great bonus but not the main motive.
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
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.
> 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.
Simply don't buy Nvidia. Apart from that there shouldn't be a lot of hardware requiring blobs on the desktop.
I don'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.
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.
Why couldn't we have long term supported kernels with decoupled drivers?
Discussion: http://lkml.iu.edu/hypermail/linux/kernel/1604.0/00998.html