How Google's Android Maintains A Stable Linux Kernel ABI

[mikahawkins]

Hello,
The Linux kernel is an extremely important part of the software on nearly every Android device. This section describes Linux kernel development and release models (below), stable and long-term supported (LTS) kernels (including why all Android devices should use stable releases instead of cherry picking patches), kernel configuration and hardening, requirements for interfaces and the modular kernels (introduced in Android O), kernel debugging and network testing, and SquashFS.
Regards,
Mika Hawkins

[SystemCrasher]

"Android Next Generation" aims to make kernel modules more portable between kernel images and devices.

Really epic waste of manpower. And all that idiocy instead of joining efforts with upstream, mainlining stuff and then merely using latest shiny kernel + maybe eventually updating very few core system libs. This also ensures proper security fixes of all known vulns, bugs & so on, while bringing just some module ... hardly addresses that. And so instead of working on real solution Google joined epic windmill fight. Whoa.

That the wrong point of windows history. You need to read Windows 3.5 NT and Windows 95 kernel ABI promise. Then you watch this be stretched. 3.5 NT and 95 kernel ABI stability was only meant to be until the service pack.

Ahh at the end of day it f..d up ReactOS so well... poor copycats don't even know what particular subflavour of windows they try to mimic. At which point they end up with most windows drivers backfiring, he-he. I guess windows users could laugh on it ... but somehow when they dare to try major OS version upgrade it quickly turns them into crybabies, since quite often there is no driver for some of their hardware. Btw I had some funny success stories retrofitting "troubling" PCs with Linux instead of Windows - somehow Linux tends to be better about hardware support these days. It sounds funny, but, dammit, that's how world works these days. Attempt to use windows version other than pre-installed is quite an adventure with unknown outcome. It has been a major problem on mobile devices, but now it appears to be problem even on more common PCs and laptops as well. I dare to say MS killed off system programming for their OS really well - so now they can enjoy all the fruits it brings.

[skeevy420]

I have a smartphone with Android 8.1.0 which uses kernel v3.18 (compiled Aug 11th 2019 / gcc 4.8 / security patches Aug 1st 2019).

If my phone gets the update its Korean variants just received I'll have that kernel version too

[c2p_]

Huh. Well I'll be damned. Here I was thinking their method was to stick with old kernels.

I don't think I have a single Android device that runs newer than 4.0.X and my current tablet and phone both run 3.1X (3.10 and 3.17).

I have a smartphone with Android 8.1.0 which uses kernel v3.18 (compiled Aug 11th 2019 / gcc 4.8 / security patches Aug 1st 2019).

[oiaohm]

The problem with using Windows as an example is that some hardware says "works on Windows XP" (or pick your flavor of choice). Well, WinXP was supported for like 10 years or more. That's way longer than what I'm talking about.

That the wrong point of windows history. You need to read Windows 3.5 NT and Windows 95 kernel ABI promise. Then you watch this be stretched. 3.5 NT and 95 kernel ABI stability was only meant to be until the service pack. As I said road paved with good intentions. What google is talking doing now is exactly what early Windows in fact promised and then due to pressure it grew out to 10+ years.

The other problem with Windows and Solaris is that the majority of your drivers are closed-source / out-of-tree. So, the coordination effort is much greater, whenever there's a desire to change something.

Now yes. When both Windows and Solaris started ABI stability 95 percent of the drivers were in fact in tree of both windows and solaris.

With all that said, I think the real issue is that many who are opposed to any kind of ABI stability are (at least partially) using it as a lever against out-of-tree drivers. This will work, as long as Linux remains in a dominant position. As soon as that falters, it will be one element of Linux' undoing. I'd rather Linux evolve and remain relevant, but I won't go down with a sinking ship. I'd suggest those with a deeper stake in Linux' future take this issue more seriously.

Its lack of abi stability that have forced a lot of drivers into Linux kernel mainline this was in effect before Linux kernel was in the current dominant position. ABI instability causing drivers to be mainline into the Linux kernel has nothing todo with dominant position. This shows you are just looking at current to make your point of view not looking back across the history.

Those with a stake in Linux kernel future to take this serous-ally because its important that the kernel can change as hardware evolves this requires drivers to be able to change. If ABI on drivers means kernel space cannot change to match current day hardware it comes trouble very quickly.

I also feel like you have an agenda that you're not really disclosing.

I do not have an agenda. I am specialist in forecasting outcomes by studying history. Part of this means you must compare apples with apples in timelines. So google is starting abi stablity you have to look when other groups attempted abi stablity at the start and see how well what google is offering aligns to this.

My read on history could be wrong. But if google with their ABI stability plan has not read the history of the other that have done it the will not put in the required counters to adverse effects.

Like one counter would be if you wish to use the google stable ABI for Linux you must also release the source code of that driver so it can be updated by someone else latter if the ABI ever has to change.

Kernel ABI stablity + closed source driver hinders development really quickly. Remember libhybris and android user-space graphics drivers. This is not the first time google has created a stable driver ABI either prior ones were userspace with android. These closed source userspace drivers did end up coming a performance and security bottleneck.

So google kernel driver ABI thing is also like kdbus as a solution to dbus-daemon problems that Linus said was a really bad idea.

coder this is Google second attempt at doing a driver ABI for Linux. Track record of the prior one was basically a failure too.

I remember nuse what was fuse modified for network devices that shows that userspace drivers can have the same performance as kernel base ones. These userspace driver-space interface also provide example of what happens as kernel space and stable driver ABI move out of alignment with each other design.

Basically there is a lot of information that a stable kernel ABI driver is a bad idea. A lot of people forgot we have the fuse, cuse and nuse history to look at as well on what will happen to performance as the driver ABI and the kernel internal design goes out of alignment.

[coder]

This idea does not hold up in the real world examples Solaris , windows....

I don't accept those examples, since the only open source one is FreeBSD and that's too niche.

The problem with using Windows as an example is that some hardware says "works on Windows XP" (or pick your flavor of choice). Well, WinXP was supported for like 10 years or more. That's way longer than what I'm talking about.

The other problem with Windows and Solaris is that the majority of your drivers are closed-source / out-of-tree. So, the coordination effort is much greater, whenever there's a desire to change something.

Next issue: money complicates matters. There are lot of scenarios and permutations to this, but suffice to say it never makes things easier.

With all that said, I think the real issue is that many who are opposed to any kind of ABI stability are (at least partially) using it as a lever against out-of-tree drivers. This will work, as long as Linux remains in a dominant position. As soon as that falters, it will be one element of Linux' undoing. I'd rather Linux evolve and remain relevant, but I won't go down with a sinking ship. I'd suggest those with a deeper stake in Linux' future take this issue more seriously.

The other cynical explanation is just developer-laziness. However, that would be an entirely unfounded accusation from me, since (as I said), I really have no background in this area.

I also feel like you have an agenda that you're not really disclosing.

[coder]

Occasionally Google updates parts of the userland to require certain kernel features to be present. When that happens then the userland needs kernel updates.

Yup. Features are added within an API level, and API levels are tied to Android OS releases, each which have certain kernel requirements (as mentioned in a previous post).

https://source.android.com/setup/start/build-numbers

[coder]

The only proper fix is for the drivers to be upstreamed.

Perhaps, if you're only concerned about the issue of driver support for a given kernel. However, having more stability, around these interfaces, would also make it easier to maintain and back-port patches to both drivers and the core.

If you accept that view, there are a lot more stakeholders to consider - many of them even acting in good faith with respect to GPL.

[oiaohm]

And they hired an important former Apple staff member Apple as well, so it's not just old-school Google employees working on Fuchsia:

Microsoft did the same thing with failed Singularity OS. Please remember the 20 percent time idea applies to new employees as well.

Also, Huawei is helping shape Fuchsia, so it's not just the 12 Google employees working on it:

That is before the trump mess. You can see that his commits have stopped. Huawei developer in mix gave access to HiSilicon future chips. To be a future OS you need the hardware developers on side to make drivers for unreleased hardware.

They are working with a few vendors, including Honor, on Fuchsia-powered devices, so it's not a mirage at all.

Its a mirage the few vendors. Honor is a solely own subsidiary of Huawei. Google + 1 vendor is all you have been looking at. Yes that one vendor has many solely own subsidiaries so it looked to those who did not look closely that there were many entries when there was only one.

I can give something historically equal that got devices out the door and stilled died.

https://en.wikipedia.org/wiki/MeeGo

The only people currently working on Fuchsia is google personal. The trump trade war stuff has in fact done a number on Fuchsia to the point we may not see any released products or just a token amount.

Making a operating system without hardware vendor support is normally a dead end may take a while to admit it. I would have more faith Fuchsia future if google acquired Motorola was still able to make current generation cellular modem chips but they cannot so google needs a hardware vendor to make a phone and that is what Fuchsia lost recently. Now can Fuchsia replace the lost hardware vendor this is going to be interesting.

[Vistaus]

https://www.businessinsider.com.au/g...-policy-2015-4

That is not straight forwards. Google has this 20 percent time idea that keeps their developers happy. So at google a stack of staff and work on a project without any major plans for it going anywhere.

There have been some quite spectacular R&D OS developments that have just dead ended in time due to hardware support issues. Good example Singularity OS from Microsoft. 7 years of full time development team not a final product and not a final product was the result of Singularity OS.

You can extract stats from the fuchsia git. You will find if you do its a total of 12 individual developers all from google. There are no hardware vendors making drivers in the mix.

12 developers working on fuchsia total there is over 10000 at google working on Linux in different areas. Fuchsia gets a lot of press but its development team is only the size of a company expendable R&D team. Singularity OS that failed was a team of over 200 so Fuchsia is not highly resourced.

Vistaus is google developing their own kernel or are they just after a kernel where they can mess around with ideas then end up taking up stream into Linux? Or worse is fuchsia just developed by google to be a barging chip? Time will tell. Until we see products shipped with Fuchsia we will be guessing. That right up until Google ships products with Fuchsia its just a mirage of a future OS that may not have any real world usage or any long term development. Fuchsia at this stage is no different to walking into a planning office and seeing a nicely planned out future city that never comes into real world existence yet people are attempting to write how life will be in that city.

They are working with a few vendors, including Honor, on Fuchsia-powered devices, so it's not a mirage at all.
And they hired an important former Apple staff member Apple as well, so it's not just old-school Google employees working on Fuchsia: https://www.androidpolice.com/2019/0...us-fuchsia-os/
Also, Huawei is helping shape Fuchsia, so it's not just the 12 Google employees working on it: https://www.gizchina.com/2019/08/01/...le-fuchsia-os/