
With Android Oreo, Google is introducing Linux kernel requirements - rbanffy
https://betanews.com/2017/09/03/android-oreo-linux-kernel/
======
MattSteelblade
Describing Linux as "horrendously difficult to use" is disingenuous at best.
There are so many different variations between distros and what people mean
when they say "Linux" that to categorize them all in this tone is hardly
professional. I'm not familiar with betanews.com, but it does claim to be a
tech site.

~~~
rayiner
That's part of the problem. You face a problem, look online for a solution,
and find answers that pertain only to different distros than what you're
using. It hasn't gotten much better as far as I can tell. I used Linux as my
primary desktop for a few years around 2002-2005 (Red Hat, Fedora, and
Ubuntu). Back then, configuration was mostly automatic, though you had to do
stuff like install the NVIDIA kernel blob manually. When things broke, it was
at least possible to fix it by dropping into the CLI.

I recently tried to set up Fedora running a VNC or RDP server, and after a
couple of days of futzing I gave up. I guess Wayland has managed to regress on
that from where X was a decade ago? Systemd also made startup issues
impossible to debug, and also apparently f--ked up with how log files are
stored? It's a mess.

~~~
unethical_ban
First of all, I disagree flatly that Linux is hard to use and troubleshoot.
Google "blah ubuntu" or "blah fedora" and you get an answer. This isn't 2002.

Second, systemd troubleshooting and RDP servers are not common uses for
Grandma, so even if valid points were made, most users aren't affected.

~~~
hungerstrike
We had Google in 2002 and the answer would probably have been easier to find
at that time since there wouldn't be hundreds of different Ubuntu versions and
sub-distros to clutter up the results. I can't count the number of times I've
found an answer that applies to "Ubuntu" where the alleged solution didn't
apply to the version that I'm running.

Also, systemd can cause anyone problems - I'm not sure it can distinguish
between you or Grandma.

~~~
cat199
And this situation doesn't apply to windows or macos how, exactly?

~~~
danieldk
_since there wouldn 't be hundreds of different Ubuntu versions and sub-
distros_

There are no macOS or Windows subdistros. So, the only difference may be
between different versions. Adding to that, Apple generally does not have the
tendency to replace/rewrite macOS subsystems every few years, so it is much
more likely that thing still work after a couple of years.

~~~
belovedeagle
> There are no ... Windows subdistros

That's a pretty naive trust in Microsoft's _branding_ / _marketing_ team. Of
course there are heaps of different Windows distributions. They don't
necessarily differ as much as, say, Ubuntu vs Gentoo, but they do differ.

------
swiley
This appears to be the source:
[https://source.android.com/devices/architecture/kernel/modul...](https://source.android.com/devices/architecture/kernel/modular-
kernels#core-kernel-requirements)

Device tree is mandatory and vendors are encouraged to upstream the code. It
sounds like Google has an eventual goal of building a single kernel that can
boot on most devices which is a great thing for everyone.

~~~
fmntf
I do not think it can be done. I am mantaining a kernel for ARM a family of
SBCs. Device trees are great compared to old platform files, however they are
not enough. We have a lot of commits to fix other things that DT cannot
access.

~~~
Khol
I'm curious as to what things DT cannot access. Is this a general issue (and
if so have you spoken to the DT maintainers?), or is this because the systems
you are working on are doing something unexpected?

~~~
simias
I've had situations where we had to add a small functionality to a driver. For
instance a secondary functionality that wasn't supported in the upstream
version. It's very rare for drivers of complex components to support 100% of
the functionality.

An example that comes to mind was a video chip that also had a GPIO pin that
we needed to control. The chip had a driver in the kernel but it didn't have
support for the GPIO (it is after all a very secondary function). That
required a small patch.

It would of course have been possible to upstream it but then that meant
implementing a "clean" patch (using the kernel GPIO API etc... instead of a
one liner to toggle the PIN high on dereset) then submitting it upstream,
maybe doing a couple of back and forth... Some will bother to do it, many
won't.

~~~
castratikron
Drivers can be built as modules most of the time. Google could still ship a
single kernel binary and any vendor that had a weird quirk could load their
own module. In fact I wouldn't be surprised if Google requires every driver to
be built as a module and they ship a minimal core kernel.

~~~
fmntf
Unfortunately there is no binary compatibility between modules and different
kernels. Moreover Google recommends CONFIG_MODVERSIONS=y, which prevents to
load even practically compatible modules.

~~~
rbanffy
The vendor would need to recompile their modules for every kernel Google
releases, but that's not a huge issue - how many times does Google update the
kernel?

------
TazeTSchnitzel
AIUI, the situation until now has been that essentially, every Android device
released has its own fork of Android. Which is absurd, and explains why the
Android security update situation is such a mess. Glad Google are trying to
fix this.

~~~
_pmf_
> AIUI, the situation until now has been that essentially, every Android
> device released has its own fork of Android. Which is absurd, and explains
> why the Android security update situation is such a mess.

The situation is the same for all embedded Linux devices. All have non-
mainlined (and non-sidelined) changes to device tree, startup code, pin muxing
code, special kernel parameters, special drivers, specially adjusted drivers,
special vendor drivers that are C wrappers around binary blobs etc..

Out-of-tree maintenance is possible, but this still often needs to build
against the kernel sources, not some more generic kernel library (or ABI, if
you want). Other embedded platforms are worse (eCos), some are better (QNX,
MQX) in separating device driver code into units that do not depend on the
whole world.

Kernel maintainers are very vocal in saying "it's not me, it's you" and
laughing in your face, but if every vendor has the same issues with managing
in a sane way customization of your operating system since a decade and a
half, it becomes a bit of a running joke.

~~~
zanny
> if every vendor has the same issues

Except every vendor _doesn 't_. By some magic voodoo witchcraft, x86 remains
consistently capable of producing a single kernel that can run on anything
from Intel or AMD.

Because they upstream their platform support.

That is literally it. No, it is not a technical impossibility of the ARM world
to support common hardware abstractions like IBM-PC platforms. They choose not
to.

~~~
RandomOpinion
> _Except every vendor doesn 't. By some magic voodoo witchcraft, x86 remains
> consistently capable of producing a single kernel that can run on anything
> from Intel or AMD._

The "magic voodoo witchcraft" is Microsoft's "Hardware Compatibility
Specifications for Windows".

[https://docs.microsoft.com/en-us/windows-
hardware/design/com...](https://docs.microsoft.com/en-us/windows-
hardware/design/compatibility/1703/)

Linux and the other free OSes run on commodity x86 hardware by targeting the
same Microsoft-issued specification. There is no standards body or other
neutral organization that defines what an x86 PC is.

------
sverige
Some have speculated that Fuchsia will eventually replace Android. I remember
back in May that some prototype UI was introduced by Google. Anyone know of
any recent developments on this front?

~~~
remir
Magenta (their new microkernel) is being renamed Zircon as they reorganize the
OS into layers named on gemstones.

As for the UI, their new compositor requires a GPU with Vulkan support to make
it run. Unfortunately QEMU doesn't support Vulkan at the moment, so I wasn't
able to test it.

~~~
pjmlp
Interesting, so they are ruling out everyone that has computers older than two
years.

And given that Android 7 (where Vulkan is anyway optional), is about 13%, I
wonder what the target users would be, if this ever gets out of the lab.

------
fithisux
The only kernel requirement that they should mandate is that the kernel should
remain blob free. Checkout/build/boot.

~~~
ryukafalz
And when the (often device-specific) kernel you're checking out has known
vulnerabilities that have long since been fixed in mainline?

Yeah, no, I'm glad they're doing this.

~~~
pritambaral
If the device-specific kernel doesn't require blobs, it is easier to upstream
the changes. If the device-specific kernel requires blobs on top of mainline,
you're screwed either way.

~~~
ryukafalz
Well, true - though in most cases I'd imagine the blobs are firmware that
would otherwise be burned onto the peripheral ROM and aren't too closely tied
to the kernel itself. IANAL, but you'd have a heck of a time arguing that a
blob shipped with a device's kernel wasn't a derivative work if it linked with
kernel sources.

On the other hand, it's _possible_ to upstream the changes, but if you're
dealing with anything like Qualcomm's 1.7 million line kernel fork[0] it's
exceedingly unlikely if you're not the SoC manufacturer. And if you're not
able to upstream them, you're stuck backporting security patches til the end
of time/you throw the device out.

[0]
[https://events.linuxfoundation.org/sites/events/files/slides...](https://events.linuxfoundation.org/sites/events/files/slides/stephen-
boyd-elc.pdf)

------
coretx
Why and what kernel requirements does Treble have ? What's wrong with kexec or
similar non proprietary solutions ? I'm not a kernel hacker but human enough
to turn suspicious when something receives nothing but good news. Can anyone
please shed some light ?

------
bitwize
Looks like they want to have certain security features enabled so Android can
maybe catch up to where iOS was a year ago.

~~~
bitmapbrother
What security features would those be?

~~~
bitwize
I don't know, but my guess would be process namespaces, cgroups, and TPM
support.

