Just like RHEL/CentOS, couldn't Google maintain a stable kernel ABI throughout a given android major release such that manufacturers could write a driver once, and have it continue working for the lifetime of that major android release?

I'm sure they could. Although it seems they would much rather move away from the Linux kernel altogether. Who knows what sort of ABI stability timescales they are aiming for in the replacement kernel.

The pertinent question is how Google think they're going to convince Qualcomm to write drivers for their new OS, and not just have exactly the same problem they have now. Qualcomm probably quite like the current arrangement where they get to deprecate everyone else's gear on their own schedule.

With wall street's love for next-quarter accounting, I'm sure Qualcomm will consider the offer, even if it's a one-time bump.

Qualcomm is dominating the SoC industry, in part due to how it uses its IP. Fortuitously, Qualcomm are being sued by the DoJ and Apple for anti-competitive practices in multiple jurisdictions and this might blow the SoC field wide open, depending on the rulings. If other chip makers can license Qualcomm's patents on a FRAND basis, Google could offer the deal to MediaTek if Qualcomm declines.

> The Linux kernel is at the very heart of Android's update problem - not because of "modularity" but because it lacks a stable ABI.

What are you referring to when you say the Linux kernel ABI is not stable? I ask because the A in ABI means application, and Linux has maintained a consistent ABI for decades.

I have a suspicion that you're trying to suggest that in-kernel interfaces be kept rigid and unchanging to satisfy some unspecified number of out-of-kernel driver developers. The simpler solution would be for out-of-kernel driver developers to get their code up to quality and merged into mainline so that they'd be ported automatically whenever there's an in-kernel api change.

> The simpler solution would be for out-of-kernel driver developers to get their code up to quality and merged into mainline so that they'd be ported automatically whenever there's an in-kernel api change.

Or we could drive linux into irrelevance and not have to worry about that anymore. Windows and MacOS users do not have to suffer from this, why should users of an open source operating system? I for one welcome Google in cleaning out this mess with a competing kernel. You know your suggestion will never happen, you know some hardware manufacturers will never open their drivers, and some just can't be avoided (people doing GPGPU work will not switch from NVIDIA, most gamers won't switch from NVIDIA, NVIDIA is owning the GPU market for the purpose of machine learning with their SOC and is working on a lean vulkan driver for linux for things like Tesla's self-driving cars).

During the early days of constant wifi APIs churn within the kernel, there were many, many out of tree drivers that ran perfectly fine but took a very long time to get mainlined because hey the kernel devs have """standards""" as they like to call it. I couldn't use a distribution that was prone to upgrading its kernel version, like Fedora, because those out of tree drivers broke on a regular basis. One of Ubuntu's major advance in its very early days was to provide fresh software every 6 months while keeping a kernel that was in sync with all those drivers and they integrated said drivers into the distribution. That gave a middle ground between using something like Fedora/debian unstable with constant breakages, or suffering the glacial pace of debian stable.

... until I discovered NDISWrapper. An implementation of the Windows API for network drivers. Yes, really. It worked so good, and because it was a well maintained project, it quickly got updated to new kernel APIs and allowed anyone with any of the working windows drivers to be freed from this suffering. It was great. Nowadays the linux kernel has support for most wifi chips in-tree (Broadcom is still a problem though) but in those days it was truly liberating to be able to use Windows drivers in linux.

Talking about wifi drivers, the Windows XP driver for my first usb wifi adapter still worked in Vista and 7 despite the manufacturer never updating it. Identical driver binary working on 3 OS generations. Talk about commitment to not breaking things. NDIS 5.1 was "deprecated" for NDIS 6.0 but MS kept the support for it for as long as reasonable for the age of the hardware.

> Or we could drive linux into irrelevance and not have to worry about that anymore

I know this is going to sound flippant, but believe me it's not: who's "we" in your sentence? Google? Because I wouldn't want to see Linux "driven into irrelevance" unless it gets replaced by another free software OS which works and is not completely owned and controlled by a single corporation. Actually, I'd rather see Linux's problems fixed or improved rather than adopting Google's brand new OS.

The problem with lack of stable driver ABI in Linux will not get resolved as long as Linus et al. are calling the shots. They are fundamentally opposed to the idea, and there's nothing you can do about it.

There's not much I can do to influence Google's vision either. At least Linux is Free software (note: I'm equally fine about other pieces of software which are not Linux but are Free software).

The Linux on a standard distribution and Linux on an Android device aren't the same thing.

The one on the Android device is a fork with quite a few APIs trimmed off, like for example UNIX V IPC.