Google Finally Shifting To "Upstream First" Linux Kernel Approach For Android Features

[yoshi314]

I wonder how this would help at all. The SoC and phone vendors don't want to provide more than 0 to 3 years of support (starting from the product launch day). Any Android device will have millions of lines of code for proprietary drivers and firmware.

features are not drivers, i believe.

[partcyborg]

The situation is a bit different though. In the Linux world, Intel's main "customers" are IT admins, who will be very pissed off if they can't use the stock RHEL (or Ubuntu, or whatever) kernel. In the phone world, the customer is an OEM who will support a small number of device models with custom kernels built for each one, and having to add some patches as part of the build process is something the end user doesn't give a shit about.

Of course there is still plenty of benefits from working more closely with upstream, which is why this decade-long android upstreaming work has been going on. Seems they are slowly getting closer, which is to be applauded.

Android handsets in the wild today already use numerous filesystems. rootfs is supported by aosp on both ext4 and f2fs, and most modern devices can mount usb keys with fat32, exfat, and in some cases even ntfs.

[partcyborg]

I don't understand how this will be possible considering how intrusive a change the HAL is. Literally Android system apis baked into the kernel, to the extent that the same kernel for a device will not boot two different major android versions.

Furthermore, the vendor specific stuff, like the bridges to the mobile side are huge. For example, qualcomms stuff in Aurora msm is simply enormous, and has it's own release cycle. I can't imagine all of it moving upstream.

[jabl]

I do not believe anyone believes 100% reliable execution in practice, but given the long lead times for most new designs/products, and the vast resources Google has available to it in order to succeed, getting the essential parts in the upstream kernel should be a reasonably achievable result (look towards Intel who tends to get new platform enablements into the kernel long before a new product ships, with the acknowledged occasional stumbles).

The situation is a bit different though. In the Linux world, Intel's main "customers" are IT admins, who will be very pissed off if they can't use the stock RHEL (or Ubuntu, or whatever) kernel. In the phone world, the customer is an OEM who will support a small number of device models with custom kernels built for each one, and having to add some patches as part of the build process is something the end user doesn't give a shit about.

Of course there is still plenty of benefits from working more closely with upstream, which is why this decade-long android upstreaming work has been going on. Seems they are slowly getting closer, which is to be applauded.

[sinepgib]

you are confused. google's business is to sell ads

You're confused. I'm talking about Android devices manufacturers there, not Google. Google doesn't make the drivers so it can't upstream them.

you forgot microsoft openly admits it has no manpower to compete with linux kernel. windows kernel supports very little hardware, very little filesystems and in general sucks

Android doesn't need to support a lot of filesystems nor a lot of architectures, and Windows successfully competes with the Linux kernel on the desktop. But more than that, it's a successful OS that runs on millions of devices and was developed by a single company. So a company definitely has the manpower to write a commercially usable kernel, and no goalpost moving will change that.

smartphone is generic computer in small formfactor, most of your list is nonsense

The smartphone may very well be a generic computer in small form factor, but Android is a constrained purpose OS for those devices, and is certainly not designed for the user to play around with settings, support multiple filesystems, implement software RAID, use arbitrarily varied socket types, do high performance routing, handle thousands of processors, support hot plug of processors and memory. I can make an even larger "nonsense" list, but like it or not, all those features are bloatware when it comes specifically to Android, it doesn't need them so the replacement doesn't need to implement them.

[pal666]

I forgot Windows is a myth.

you forgot microsoft openly admits it has no manpower to compete with linux kernel. windows kernel supports very little hardware, very little filesystems and in general sucks

Plus, when the purpose of your kernel is constrained you need a lot less manpower than what you need for something that's expected to be useful in many scenarios.

smartphone is generic computer in small formfactor, most of your list is nonsense

[pal666]

That won't happen because programmed obsolescence is the fabric of their businesses.

you are confused. google's business is to sell ads

[sinepgib]

idea that google can write non-linux kernel for android is crazy. it requires too much manpower for one company.

I forgot Windows is a myth.
Plus, when the purpose of your kernel is constrained you need a lot less manpower than what you need for something that's expected to be useful in many scenarios.
Think this:
- You don't need SysV IPC, you use Binder for everything;
- You don't need a myriad of architectures, you can for example restrict to little endian, which covers pretty much all consumer hardware other than routers;
- You can go further and only implement ARM support (even if you need the design to be flexible enough to add other architectures later), because it'll run on cellphones only and x86 failed there;
- Drivers? Most of them are up to the OEM to provide;
- Filesystems? One for internal storage, FAT for interoperability;
- No memory hotplug;
- No huge number of network protocols, just Unix, TCP and UDP probably;
- No BPF or only the classic version in case you need to debug packet flow;
- No floppy, ATA, CD-ROM, KVM, etc...

Essentially, making a kernel for Android only means you no longer need to support a lot of stuff, and also that you can break a lot of things safely because you control the userspace too. That makes it much cheaper to develop it than you would think.

[pal666]

Maintaining out of tree patches is bloody expensive due to Linux kernel developers' stable API nonsense mantra.

if you disagree with this mantra, you could cheaply maintain out of tree patches to any other more successful kernel

[pal666]

Why not switching to mainline Linux kernel entirely?

they are planning to do it:
2023-2024: Reducing Technical Debt
○Upstream First Development model for new features
○Work toward upstreaming all out-of-tree patches in Android Common
Kernels