On the one hand it gives hardware vendors an incentive to contribute their drivers directly into their kernel but on the other hand most Android phones are now restricted to one old kernel version due to the lack of ongoing support from SoC vendors.
I assume that the majority of Linux kernels are running on Android phones and due to this lack of stable ABI for drivers these kernels are all outdated or even unmaintained.
> I assume that the majority of Linux kernels are running on Android phones and due to this lack of stable ABI for drivers these kernels are all outdated or even unmaintained.
No, it's because the hardware manufacturers won't upstream their drivers. All they have to do is send the code licensed under GPLv2 and it will be updated and maintained.
Stable ABI for drivers will result in the Windows situation: hardware vendors will just release one driver for one Windows version and one processor architecture. They don't seem to care very much so why should people optimize for their comfort? The least they could do is release free software so that the people who do care can make it work well.
My laptop has a backlit keyboard with RGB LEDs. The only driver for it is a single proprietary Windows driver coupled with a buggy and slow application. I doubt these things will ever be updated.
I actually emailed the manufacturer about this. I asked for technical information in order to make it work on Linux. They didn't or couldn't help me. So I reverse engineered the keyboard, made a Linux program to control the LEDs and the result was much better than the software they wrote for Windows. At least it doesn't take a full minute to start up.
There is no point in making these companies comfortable. People should do the opposite: it should be as expensive as humanly possible to not release the drivers as free software. If they insist on maintaining proprietary drivers out of tree, then they should absolutely pay the maintenance cost. Kernel hackers shouldn't have to spend one second thinking about how a change will impact some crappy proprietary driver that's not even in the kernel tree.
What if they are ok with this? What if the device vendors use this lack of stable ABI to put an expiration date on their products?
Android phones don't get more than 3 years of support and my fear/tinfoil theory is that the vendors abuse the good intention of the kernel devs to deprecate old devices faster.
They can release drivers for a specific operating system and processor architecture. When those change and the driver breaks, they aren't going to spend time and money updating the driver for an old product they aren't even selling anymore. They'll just tell people to buy their new product instead.
> Stable ABI for drivers will result in the Windows situation: hardware vendors will just release one driver for one Windows version and one processor architecture.
Uh, I dare say Windows hardware + driver compatibility is pretty damn good, so this doesn't really resonate with me... at all. Has not being able to install Windows XP on a modern machine left you bitter...? Or have I been living in a bubble?
> Has not being able to install Windows XP on a modern machine left you bitter...?
Not at all.
I have been burned by drivers that only worked in 32 bit Windows XP though. They simply couldn't be used in newer versions of Windows. The manufacturer couldn't care less, they think I should just trash the unsupported hardware and buy the newest product instead.
Linux doesn't have this problem. Once a driver makes it into the kernel, it can be maintained, updated, fixed, refactored, improved, backported to older kernels, recompiled for new architectures. It's just so much better.
> Has not being able to install Windows XP on a modern machine left you bitter...?
Yes. The topic at hand is how newer software can screw things after all, which causes people to want to stick to older versions. The same applies with Windows 7 BTW - or whatever your favorite Windows version is.
But it also goes in the other way: being bitter that i am not able to install drivers on Windows 10 for older hardware that should otherwise work.
Windows hardware + driver compatibility is a nightmare fueled by proprietary duct-taped one-off drivers supporting only one or two devices each.
One of the reasons for this is that you can get away with anything on Windows, because everything is proprietary. There are headsets targeting Windows users that require kernel-mode drivers to work. Which, of course, is super fragile and will break at some point, rendering your expensive headset useless.
It is indeed horrifying, and the particular products I'm thinking of are indeed from a series of gaming headsets. There are other categories of headsets, speakerphones and the likes that are equally awful, though, which is why I see the problem as universal to products targeting Windows:
There is no scrutiny to stop this idiocy, and the average consumer has no idea why this is bad, and no idea that those blue screens were because of a headset.
Having a connection to said company, I'd rather not name them though.
> There is no scrutiny to stop this idiocy, and the average consumer has no idea why this is bad, and no idea that those blue screens were because of a headset.
Yeah. Microsoft doesn't exercise any control and the result is hardware manufacturers force bogus software down the throats of Windows users. The Linux community can count on Linus Torvalds and the kernel hackers to provide that scrutiny and people trust Linux a lot more as a result.
I always cite capcom.sys as an example of why random companies shouldn't be allowed to write drivers:
It is, right until you want to emulate an audio device that vastly differs from what you have (say, presenting a headset as a surround sound device and do in-driver signal processing).
> No, it's because the hardware manufacturers won't upstream their drivers. All they have to do is send the code licensed under GPLv2 and it will be updated and maintained.
You probably know this, but that's most definitely not true. After they get their code correctly licensed, they still have to get the code up to the standards of the mainline kernel, get it through reviews, plus at least act like they intend to maintain it. Probably actually do that too, if you want any future changes to go in.
> All they have to do is send the code licensed under GPLv2 and it will be updated and maintained.
That seems like a dubious assertion. I've heard several cases of driver regressions in new kernel versions, and because of the model that means you can't just use the older one.
The linux kernel does not provide a stable ABI for drivers. Drivers that aren't in the kernel source tree will eventually break.
https://github.com/torvalds/linux/blob/master/Documentation/...