Google Wants Android To Use Regular Linux Kernel (androidpolice.com) 87
Android is built on top of the Linux kernel, but it has always used a heavily-modified version with changes from OEMs, chip manufacturers like Qualcomm and MediaTek, and Google. There have been efforts over the years to close the gap between the two kernels, but now Google is getting more serious about it. From a report: At this year's Linux Plumbers Conference, Google engineers held talks about the company's efforts to get Android as close as possible to the mainline Linux kernel. Not only would this reduce technical overhead for Google and other companies, because they would no longer have to merge thousands of changes into each new Linux kernel version (and Google would no longer have to support Linux kernel versions for six years), but it could also benefit the Linux project as a whole. For example, the growing number of ARM-based Linux phones and computers could see improved performance and battery life. The first stage of this process is merging as many of Android's modifications as possible back into the mainline Linux kernel.
As of Feburary 2018, the Android common kernel (which OEMs make additional changes to) has over 32,000 insertions and over 1,500 deletions compared to mainline Linux 4.14.0. That's an improvement from a few years ago, when Android added over 60,000 lines of code on top of Linux. To show off how much progress has been made, Tom Gall, the director of the Linaro Consumer Group, brought a Xiaomi Pocophone on stage that was running Android 10 on top of a mainline Linux kernel. He told the audience, "there are major, major props to be given to the Google Kernel Team in particular for getting their code upstream so that we can boot devices with a mainline kernel." It's likely that some of the phone's features were non-functional (the battery percentage in the picture reads as 0%), but it's still impressive.
As of Feburary 2018, the Android common kernel (which OEMs make additional changes to) has over 32,000 insertions and over 1,500 deletions compared to mainline Linux 4.14.0. That's an improvement from a few years ago, when Android added over 60,000 lines of code on top of Linux. To show off how much progress has been made, Tom Gall, the director of the Linaro Consumer Group, brought a Xiaomi Pocophone on stage that was running Android 10 on top of a mainline Linux kernel. He told the audience, "there are major, major props to be given to the Google Kernel Team in particular for getting their code upstream so that we can boot devices with a mainline kernel." It's likely that some of the phone's features were non-functional (the battery percentage in the picture reads as 0%), but it's still impressive.
Great news (Score:5, Insightful)
Now if we can just find some solution to Qualcomm's binary blob hell that will allow devices to be updated past whatever short period they support their hardware for (2-3 years?).
Sam
This would be a huge win for everyone (Score:5, Insightful)
Kudos to Google for making this happen.
Re: (Score:2)
Re:This would be a huge win for everyone (Score:4, Interesting)
The difference it makes is that you will be able to compile a new kernel for your device, which is often a prerequisite for upgrading to a newer Android version. It will also have a knock-on effect to other embedded Linux systems, as mainlined kernel support will become the norm, so device developers can free ourselves from the vendor specific forks of obsolete versions.
Re: (Score:2)
Nobody is going to want to compile a new kernel for their phone. For a start, the task of setting up a cross compiler toolchain is beyond the ability of the vast majority of Android users. Then compiling a kernel is relatively easy but compiling a kernel with all the right drivers and options for your particular phone is not trivial. Then you've got to get the kernel on the phone and hope it doesn't break it.
The only benefit for end users is that it might make the lives of upstream developers easier so they
Re: (Score:2)
Re: (Score:2)
This may well be their motive, but the end effect is less work for everybody overall, so even if its a selfish motive, it is still aligned with the common good.
Re: (Score:2)
Re: (Score:2)
If drivers were mainlined that'd be great, it would mean that they're in the main source tree and could be updated as needed. Unfortunately that's not what those 60000 lines of code are, that's their own modifications before the vendors add their binary blobs and much of it probably middleware. What Google wants is to decouple and fix that interface. Obviously you need interfaces to talk to different hardware in a standardized way, frozen interfaces and black box code is more of a mixed bag. The first part
Re: (Score:2)
The number of end users who even say they need to be able to modify the OS on their Android phone (never mind actually needing) as a percentage of the total number of end users is approximately zero.
Re: (Score:2)
(Note: It's actually 98.1%)
https://en.wikipedia.org/wiki/... [wikipedia.org]
In short: I disagree. I think if we had a standard hardware platform, like we do with x86, it would allow a competitive market where people would be willing, able, and often would install a
The regular kernel is worthless (Score:1)
Re: (Score:3)
You can't get rid of the bloatware on Android without root. Of you can "freeze" applications as if that really does anything. No I want them gone and I want the space freed up.
Re: (Score:2)
Maybe you should only buy rootable devices.
Still waiting to find out if Moto is going to bring out Android 10 for my Moto X4 Android One. And they still refuse to answer, which makes me suspect not. The whole point of an Android One device is continuing to get updates...
If Motorola burns me on this I have no idea what I'll buy next. Who offers an unlockable bootloader, and actually delivers on their promises? I'm guessing nobody. Maybe I'll have to get a Pine phone?
Important, but not mentioned in the summary (Score:5, Interesting)
This actually means that Google wants to change how the "mainline Linux kernel" functions, and at least some of the Linux core developers are against this.
From TFA:
"The idea proposed by Google engineers is to build an interface in the Linux kernel that would allow proprietary device drivers to run as plug-in modules, so no modifications to the kernel itself are needed. In simple terms, it would bring the modularity of Project Treble to regular Linux.
Of course, this is a massive undertaking that isn't guaranteed to succeed. Google would have to get its Android hardware partners on board, and as Ron Amadeo from Ars Technica pointed out, some of the Linux community is against the idea of a stable kernel interface. Greg Kroah-Hartman, a major developer for Linux, has already written this in documentation files:
'Linux kernel development is continuous and at a rapid pace, never stopping to slow down. As such, the kernel developers find bugs in current interfaces, or figure out a better way to do things. [...] This is in stark contrast to a number of closed source operating systems which have had to maintain their older USB interfaces over time. This provides the ability for new developers to accidentally use the old interfaces and do things in improper ways, causing the stability of the operating system to suffer. [Also,] if the internal interfaces were not allowed to change, fixing [a] security problem and insuring that it could not happen again would not be possible.'"
Re:Important, but not mentioned in the summary (Score:5, Insightful)
"The idea proposed by Google engineers is to build an interface in the Linux kernel that would allow proprietary device drivers to run as plug-in modules, so no modifications to the kernel itself are needed. In simple terms, it would bring the modularity of Project Treble to regular Linux.
Oh, what's that I hear? Is that the sound of the "Monolithic Kernel" "strengths" argument being outweighed by, um, Reality?
Re:Important, but not mentioned in the summary (Score:5, Insightful)
No, from reading the rest of the GP post, it's clear that these Linux developers *don't* want this module idea to hinder the strengths of their monolithic kernel, because it doesn't outweigh them. They most likely don't care much at all about the main feature that the module idea benefits: proprietary binary blob drivers that never get updated.
Re: (Score:2)
Whether a kernel is monolithic has nothing to do with whether is supports plugin modules or whether the ABI for those modules is stable.
The only non-monolithic kernel with any marketshare is AFAIK QNX. (And you could argue MacOS, but running a monolithic BSD as a task does not really count.)
Re: (Score:2)
macOS is monolithic. It does have a stable plugin driver architecture though.
The problem with Linux (or the strength depending on your point of view) is that the binary interface for its driver architecture (which also supports plugin modules) is not stable. This means that hardware manufacturers have to recompile and test their drivers for every single release of the kernel.
Re: (Score:2)
I don't know what you hear, but we hear the sound of you not knowing what a monolithic kernel is.
Re:Important, but not mentioned in the summary (Score:5, Interesting)
LTS/"Stable" ABI layer.
That's all said and good, but if you want Linux to succeed in some industries.
The reason Windows gets used in medical devices is because companies throw money at Microsoft to support a stable ABI for the full application lifecyle.
The 'run fast and break things' is a great mantra for quick development but not really for any thing functional safety related. Maybe someone (Google, VW) could fork the "Lets go really fast" mainline and develop a solid fork based on a version that can get properly beat up for ISO26262/DO178C. At least, that's what I'd like to see out of my ADAS software OS.
Or maybe Google should just go all Apple and switch to a BSD. Then they can quit trying to work around the GPLv3 for proprietary bits.
Linux isn't GPLv3 (Score:3)
> Then they can quit trying to work around the GPLv3 for proprietary bits.
Thankfully, Linux isn't GPLv3.
Re:Important, but not mentioned in the summary (Score:5, Informative)
Linux doesn't break user-facing API/ABI unless there's an extremely strong need. It's been one of Linus's core principles for decades.
Re: (Score:3)
That policy applies to the userspace ABI. Google wants a stable kernel module binary interface, which the userspace ABI doesn't cover.
Re:Important, but not mentioned in the summary (Score:4, Insightful)
There are plenty of Class 3 medical devices running Linux so I call B.S.
Windows gets used in Medical devices only because of inertia and incompetence.
Re: (Score:1)
Re: (Score:1)
Re: (Score:2, Informative)
The good news is that you are too stupid to make any application beyond "Hello World", so no one needs worry.
Re:Important, but not mentioned in the summary (Score:5, Informative)
Re: (Score:2)
Re: Important, but not mentioned in the summary (Score:2)
You can't say kernel ABI to hand wave away the problems Linux has with stable interfaces.
Real world developers either care about stable APIs waaaaaaaay beyond just libc, or stable kernel interfaces for drivers. Linux systems have neither.
https://access.redhat.com/arti... [redhat.com]
Look at that.. libxml2 is in compat level 1, openssl and libz are in level 2... outstanding.
Also note the huge static linking to the c runtime warning, maybe RedHat is just making that up, shouldn't be a problem right?
Re: (Score:3)
Re: (Score:3)
Re: (Score:1)
in fact... your angry and meaningless reaction suggests that those who have no experience in making large systems are yourself, because otherwise you would understand the problem I am describing.
Re: (Score:3)
If you say so. But since your reason doesn't match reality as I perceive it, I can't take your opinions seriously.
OTOH, it's nice to have another person who doesn't like systemd.
Re: (Score:1)
Re: (Score:2)
Chances are not that great. My employer had to scrap some really high-end printers - the type that have eight different ink containers and print in A3 size in photo quality- because the manufacturer ceased to release any new drivers after Windows Vista, and the Vista ones could not be abused into working on Windows 10.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
You can install a Vista driver, but it doesn't always work. In this case, it didn't.
Re: (Score:1)
Re: (Score:2)
You only have the binary. Whether the API is stable matters not at all to you. You cannot recompile the application to take advantage of the stable API.
Luckily the Linux kernel offers a stable ABI. You will have to dig up the appropriate old libraries, but that is generally true on Windows as well. (Except there is a good chance that the application bundles those in the Windows installer). Just snatch them off an old Yggdrasil CD or something.
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
i'm noticing a lot of really angry kids because i've committed the "heresy" of pointing out a serious problem with their favorite operating system ... Grow up kids, doing petty "moderation war" won't change nothing.
https://twitter.com/dril/statu... [twitter.com]
Re: (Score:2)
I don't want to make an application that could cost millions of dollars to operate on Linux if the next month an important OS interface ceases to exist
The Linux syscall interface - the kernel's API to userspace (where applications run) - has a very long deprecation time. Syscalls that were deprecated in 2004, weren't actually removed until 2015. Other then that, only new syscalls have been added - and only after a lot of consideration and discussion.
libc is not part of Linux. In fact, it is supported on MS Windows, as well as MacOS, the various BSDs and others, not just Linux.
Re: (Score:2)
On the other hand it would help make Linux more attractive for a lot of systems. The IoT world is crying out for something like this that lets people keep devices reasonably up to date without to much effort on the part of the manufacturer.
Re: (Score:2)
Why couldn't Google maintain a namespaced API translation layer that would provide a stable kernel API for some number of years/releases?
If the kernel devs refactor something then the Google devs can provide the original API and call the necessary new kernel API. Sure there is a tiny performance hit, but if the alternative is no security updates, then just suck it up. Do I want five-minutes less battery life or to have my bank account drained? Ideally, neither, but this is 2019 still.
Re: (Score:2)
s/API/ABI/g
Re: (Score:1)
Such an interface already exist to add a loadable kernel module at runtime using the modprobe utility. Besides adding a proprietary driver isn't that difficult. My linux box run the Nvidia drivers with no problem apart from a warning msg at boot: “nvidia: loading out-of-tree module taints kernel.”
How to load a [slashdot.org]
Torvalds doesn't want an ABI (Score:3)
Someone was interviewing Torvalds maybe 10 years ago and asked why no ABI in the Linux kernel?
Torvalds explained that the reason people want an ABI is so they can link closed-source code to the kernel.
When that code has bugs, he ends up debugging the kernel with incomplete sources.
He doesn't like doing that.
So, no ABI.
Re: (Score:1)
"The idea proposed by Google engineers is to build an interface in the Linux kernel that would allow proprietary device drivers to run as plug-in modules, so no modifications to the kernel itself are needed. In simple terms, it would bring the modularity of Project Treble to regular Linux."
Which actually is what Google is ultimately aiming for; to avoid having to make changes to the kernel and to return to mainline Linux kernel, whilst letting people make their proprietary drivers using it. And for that, Google needs to take the LTS/Stable route in terms of mainline Linux kernel.
Why you need the kernel to display battery status (Score:1)
Seriously, what does the kernel have to do with battery percentage?
I admit i never studied phone hardware designs, but i imagine it's just like almost anything else digital, including our PC's, and that would mean that the battery monitor is attached to some bus, I2C, for example, that the CPU accesses. And with Linux, it's trivial to provide userland access to such bus.
When it comes to other hardware (video, modem chips) etc i can imagine you need some drivers but for that kernel modules were invented if i
Re: (Score:2)
Well, if you want to talk to hardware that's not on one of the peripheral buses (PCI, USB, etc), you probably have to go through a "side door" on a core system chip. Which probably means you have to talk through the kernel for security reasons.
Re: (Score:2)
> Seriously, what does the kernel have to do with battery percentage?
I'm just hypothesizing, but I'd imagine its because on mobile devices, power management is a huge deal, and lots of stuff gets throttled to minimize battery usage depending on desired speed / power tradeoffs. Modern CPUs can dynamically disable or throttle cores, GPUs can run in more or less aggressive modes, and so on. All that is going to mean kernel-level code.
Modern lithium-ion batteries also need code to correctly manage charging
Microsoft Wants This Too! (Score:5, Insightful)
Microsoft also want it's OS's to run the Linux kernel. They just need Linux to migrate to NTKRNLMP.EXE and everyone will be happy.
Seriously though, Google doesn't want Andriod to use the Linux kernel, rather they want the Linux kernel to adopt their changes.
Re: (Score:2, Insightful)
They did. But forks are expensive. It's almost as if you're too stupid to breathe. Certainly too stupid to understand the summary.
ARM in general needs to get its act together (Score:5, Informative)
Re: (Score:1)
The ARM world needs to make its peripherals discoverable. It is a pain in the ass that every little variant of an ARM board needs its configuration "upstreamed" because there's no way to reliably find it by running some generic code on the thing. Bonus points if they come up with something sane instead of adopting EFI.
Yeah - I find it irksome; it should be as simple as updating the FDT, but I've learned a few things while trying to get FreeBSD onto ESPRESSObin.
Re:ARM in general needs to get its act together (Score:4, Informative)
Re: (Score:3)
It would be nice if ARM had a standard mechanism for booting, so closed source kernel blobs are not needed. In addition, it would be nice if the worlds functionality was open and accessible, as that would provide for some excellent containerization functionality.
I have a feeling the cool stuff will wind up with RISC-V, although I don't know how well that will be adapted, as it isn't as great for power as the ARM CPUs are. Although having a chipset that isn't patent encumbered wouldn't be bad.
Binder (Score:1)
Without Binder kernel patches we'll need some daemons to manage the lifespan of message objects and there will be multiple copying steps instead of the zero copy infrastructure that binder enjoys today. Basically you get everything that D-Bus does without the bloat and instability.
Just like file-systems, IPC mechanisms can usually be best managed in kernel. How many IPC subsystems do we need? One if it's good, four or five if none of them are good. Luckily Binder is way simpler than any of the major filesys
Re: (Score:1)
Re: (Score:1)
This reads like a sales pitch.
Thanks!
I'd also like to add that Binder is part of the main line source, but few distros build it. I would not consider it being enabled as part of a "regular Linux kernel".
I believe every feature in a major software package needs to have some justification behind it. In an open source kernel nearly everything is up for debate, which I think you sensed in the tone of my earlier post.
One worry. (Score:3)
One thing with smart phones compared to PC's is the OS has been very locked down. While an annoyance to those who know what they are doing, and wants their phone to do that one more thing. It also means those who do not, doesn't download crap as easily that causes malware on a device that is in their pocket all day long, connecting to different networks all day.
I don't buy just because it is Linux it is free from these problems. Security is part technology and part behavior. The locked down OS of Android and iOS mostly restricts peoples behaviors unless they are really trying.
Re: (Score:2)
Linux is definitely not free of downloadable malware. This has long been known. The barrier is between system space and user space. Even there there are holes found, though they get fixed fairly quickly.
If someone has root access, there's probably no way to ensure they aren't tricked into giving malware root access. The current Linux user environment is relatively safe because it's more difficult to trick users when there are a large variety of environments that they are operating in. It's become less
Improvement? (Score:2)
>has over 32,000 insertions and over 1,500 deletions compared to mainline Linux 4.14.0. That's an improvement from a few years ago, when Android added over 60,000 lines of code on top of Linux.
Are you sure that's an improvement? Are insertions counted per-line, or per-block? If you're counting per-block then if you averaged two lines per block you'd be up to 64,000 lines added - hardly an improvement.
Assuming they're counting single-line insertions, it is an improvement... but they've got a lot of work
Re: (Score:1)
>has over 32,000 insertions and over 1,500 deletions compared to mainline Linux 4.14.0. That's an improvement from a few years ago, when Android added over 60,000 lines of code on top of Linux.
Are you sure that's an improvement? Are insertions counted per-line, or per-block? If you're counting per-block then if you averaged two lines per block you'd be up to 64,000 lines added - hardly an improvement.
Assuming they're counting single-line insertions, it is an improvement... but they've got a lot of work still to do.
These metrics are bogus. Any metric that's reduced to a count doesn't factor in quality of code.
mostly device and SoC drivers (Score:2)
Simples (Score:2)
Google have seen that Go has taken off like fricking rocket over the last 2-3 years and Java is a major pain in Google's ass while they fight a constant battle with Ellison's beast Oracle Corp over Java's usage. Google has had ton of grief about bad apps in the app stores with scam ads and such like. Fast forward 2 years, Android is now a Linux derivitive, you want to release and app to the Google app store then you upload the app's Go source code securely to Google. Google then compile it, test it and chec
Re: (Score:3)
Misleading title (Score:1)
I think Google is not saying that it will use mainstream kernel. More like, "We will maintain only a small bunch of kernels (outside of vendor specific drivers)".
Well... They may tray to put their ABIs in mainstream kernel but I guess it will fail. But the idea of ABIs it mostly avoid a branch for each vendor but only for ABI releases.
And if the ABI (v1, v2... etc) could be ported to new LTS kernel, then it will allow very old drivers to run in very modern software.
It's time. Actual devices has a lot of res
Re: (Score:1)
I have been wondering this for years (Score:2)
Re: (Score:2)
going on for years (Score:2)
they've been doing this for years and years already, trying to get in line with the standard linux kernel.
really, does it even matter at this point?
- the android linux kernel source is available because of the gpl
- even if they would use mainline kernel, there will be many closed blobs loaded/needed anyway
- if the bootloader is locked, why should i even care?
Re: (Score:2)
Right, all phones i buy, i make sure that the bootloader is unlocked because vendor support/updates are just horrible.
But a lot of phones don't have an open bootloader, for non-techy people this is not a requirement.
Fuchsia (Score:1)