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

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

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

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

[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

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

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

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

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

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

[oiaohm]

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.

This skips over major issue. Remember where Microsoft end up doing a deal with Qualcomm where Microsoft is having to money for drivers. Yes there is a bigger story here.

Most people are clueless to how many different ways a arm soc chip starts up. OEM vendors of android phones don't make soc chips. Yes this is even true with samsung because the OEM part of samsung that makes android phones and the part of samsung that makes SOC chips is two different companies.

Android documentation uses the term Original design manufacturer(ODM) this is the party that makes the silicon in the device, LCD.... OEM at most designs a circuit board and a case. Majority of your drivers need to come from ODMs not OEMs.

Lets take like a Samsung Soc chip you find in their phones. Questions how many ODM is that single chip. Most people incorrectly presume 1. The correct answer is at least 20 with only 1 of those being samsung. One of the worse soc chips in a mobile phone that Linux has been able to be made run on in fact has 150 individual ODM for the soc chip. There is most likely soc chips out there with more ODMs.

This is start of problem. Remember where I said Microsoft to have windows support on Qualcomm chips was paying Qualcomm money for drivers the next step is Qualcomm paying the ODMs they used in the soc chip to write drivers. With android phones you see examples where two phones have same soc chip one gets a update Android image the other does not interesting enough this can that the maker of the phone being the OEM one of them had the money to pay for new drivers and the other did not.

OEM if they provide closed source drivers they have normally had to spend money to get license to distribute the drivers. This means the ODM can refuse at any point to give the OEM new driver versions. Yes some cases ODM is refusing to provide new drivers because for some reason they went bankrupt. If the driver is a key driver the SoC chip will not function correctly without it. Please note a key driver can be a stupid reason to be a key driver like one of the Intel atom chips if you don't power up a particular bit of hardware todo nothing the SoC chip goes over voltage and shuts down. So when I say key driver not as in some key feature the OS need as in key feature that soc chip runs and is useful.

Ideal world you can do business with ODM to get all drivers open source and bundled with your kernel.

you can for example restrict to little endian, which covers pretty much all consumer hardware other than routers;

This here is absolutely not as simple.

Router being linux based and android phone being Linux based and both being arm means the ODM making the common part there has more than 1 reason to make a Linux driver. Now you make a OS that is phone only. ODM maker could decide its not worth their time.

ODM are horrible big picture people. At times they can class phones are small part of there business. Linux advantage with ODMs is due to how many places it used so it way likely to have over 60% market share of the parties the ODM is supplying to. The other 40% can be mostly made up of Windows. Now as new smart phone OS not Linux based you could be less than 4% of the ODM sales space welcome to uphill battle getting driver support.

Yes Android starting with a Linux kernel did start with existing market space in routers and other devices for ODMs that were using Linux, This is quite a hurdle to get over.

[royce]

I don't ever want to see Google's spyware mainlined into the kernel so I say it should cost them more to conduct espionage on the citizens. The more it cost them, the better.

Do you realise how many eyes look at patches before they're integrated into the kernel? Especially after the University of Minesota fiasco a few months ago.