[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"?

[microcolonel]

> 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.

[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/

[forgottenpass]

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.