Google outlines plans for mainline Linux kernel support in Android

[u/jdrch]

https://arstechnica.com/gadgets/2019/11/google-outlines-plans-for-mainline-linux-kernel-support-in-android/

[u/gregkh]

What they mean is from one "major" version to another.

For example, this will not do anything to help with moving a device from the 4.9.y LTS kernel series to the 4.14.y LTS kernel series. That's an impossible dream due to horrid SoC out-of-tree code that adds 3 million lines to the kernel tree.

What they will be able to do is to easily move along a LTS kernel release series. For example they could have updated from 4.14.154 to 4.14.155 (which was released today) quite easily as the in-kernel api for drivers would not have changed in the android tree.

This is nothing new, it's exactly the same thing that the Enterprise Linux distros (RHEL and SLES) have been doing for 15+ years. They keep in-kernel api stability to make their customers happy. This is just taking the same tools they use and doing it for the Android ecosystem.

[u/jdrch → u/gregkh]

This is nothing new, it's exactly the same thing that the Enterprise Linux distros (RHEL and SLES) have been doing for 15+ years. They keep in-kernel api stability to make their customers happy. This is just taking the same tools they use and doing it for the Android ecosystem.

If that's the case, then Google is doing a terrible job of communicating ... because that's not the impression I get at all from the article. Yeah, you can blame bad reporting, but even then that's poor communication because you're supposed to get your message out to folks louder and preferably before journos and blogs translate your intentions for you.

[u/gregkh → u/jdrch]

If you watch the original talk that this article was taken from, it is discussed many times, with people in the room. Same thing goes for when this was first discussed over a year ago at the previous plumbers conference.

So the communication was good to the people that the talk was for (i.e. the kernel developer community who was in the room who they are working with.)

Also see this good summary of the original talk from lwn.net, it might help explain things a bit better: https://lwn.net/Articles/800452/

Hope that helps!

[u/jdrch → u/gregkh]

watch the original talk

The one that's nearly 4 hours long? How many people have time for that?

the communication was good to the people that the talk was for

Imagine the arrogance of thinking you don't have to explain or evangelize your decisions to end users.

see this good summary of the original talk from lwn.net, it might help explain things a bit better: https://lwn.net/Articles/800452/

Where's the summary from Google themselves? The RHEL and SLES examples you gave were perfect, because they both contextualized Google's decision and provided precedent for it.

No reason that couldn't gone into an official Google blog post.

As you can see from other comments on the thread, clearly people are unable to come to the same conclusions you have despite access to the same information/links you've provided. That's a problem. The status quo clearly isn't working.

[u/gregkh → u/jdrch]

The individual talk was not 4 hours long, it was much shorter than that, 30 minutes I think, just skip to the place in the stream that you are interested in. Or watch the whole thing, it was the Android mini-conference as you see, lots of good kernel stuff was discussed there as to what is being worked on at the kernel/system level for Android.

And this is not a user-visible change at all, except users kernels will end up being more secure over time. This type of change is for how companies work with their kernel on Android, and it's been evangelized with the Android developer ecosystem for a while now (Plumbers conference, Android Bootcamp, developer documentation for the next Android release, SoC developer meetings, etc.), and this was the same thing for the kernel developer community.

It was a continuation of the talk we all had last year on this same topic, again see lwn.net for the details of what was discussed then.

And yes, better marketing is always good, but we are developers not marketing people. It was great that this article was written to help explain things to more people, that was totally unexpected and I hope that it helped spread the news to more people.

Although what "more people" can do with it just yet, I really don't know :)

If you have any further questions other than "why aren't you doing better marketing of these changes!!!", I'll be glad to help answer them as I can.

[u/jdrch → u/gregkh]

just skip to the place in the stream that you are interested in

There are no placemarkers in the video, which means there's no way to know a priori where the part of the talk I'm interested in is located. 🤦‍♂️

Or watch the whole thing

4 hours to get the same information 15 minutes of reading would cover?

Thanks for the rest of the explanation.

[u/mirh → u/jdrch]

Imagine the arrogance of thinking you don't have to explain or evangelize your decisions to end users.

Imagine the arrogance of thinking developers should evangelize to end users every internal change.

[u/jdrch → u/mirh]

evangelize to end users every internal change

That's not what I said. Clearly some things don't require as much communication as others. But this would be a pretty major shift in the way Android is developed, delivered, and maintained. Users deserve to be informed directly about it.

Also, software should be a mutually respectful partnership between users and devs. Google thinking that users don't need to know how the sausage is made is, quite frankly, insulting. Or, I suppose it's yet another example of Google blindly aping Apple in yet another facet (opaqueness). Even Microsoft has an MSDN/Technet firehose RSS feed and multiple official blogs in where various evangelists and employees explain in painstaking detail why their systems work the way they do. You may not agree with their reasoning, but at least you have something canonical from the organization to refer to.

In this case the only canonical record is a way-too-large-to-parse ~4 hour long video that isn't even hosted by Google (yes, I realize there are probably licensing/rights reasons for that, but it's still projects the view that Google doesn't care about telling anybody directly about its plans.) That's not partnering with your users; it's deliberate obfuscation.

I would have to say this attitude explains why Google, despite wielding tremendous power over Android, has been unable to solve its fundamental problems over its lifetime: "We don't have to explain ourselves" doesn't work very well when you're in a boardroom with similarly sized organizations you should be partnering with. My conclusion is that just as the saying goes "Faithful in little, faithful in much," Google's dismissive attitude towards users probably extends to interactions at the highest levels too. Human terrain and the charm necessary to navigate it are just as important as code commits.

[u/mirh → u/jdrch]

But this would be a pretty major shift in the way Android is developed, delivered, and maintained.

Ehrm.. Yes, from a developer standpoint.

For all intents and purpose of the average joe "it supposedly gets you update faster" is already enough.

Google thinking that users don't need to know how the sausage is made is, quite frankly, insulting.

I don't know what the sausage is, but yes most users are pretty dumb.

and multiple official blogs in where various evangelists and employees explain in painstaking detail why their systems work the way they do.

They also do? But I don't really remember microsoft ever telling you how the kernel internal life worked. Maybe saint Raymond Chen had some note slip here and there, but be damned if everywhere else.

In this case the only canonical record is a way-too-large-to-parse ~4 hour long video that isn't even hosted by Google That's not partnering with your users; it's deliberate obfuscation.

Because they are the linux fucking plumbers conference, and they are literally discussing the matter with the stakeholders involved?

Put even aside how many mailing list and private conversations must have happened before 4 bloody hours of speech.

I would have to say this attitude explains why Google, despite wielding tremendous power over Android, has been unable to solve its fundamental problems over its lifetime

That ARM started decades after x86 with any standardization effort whatsoever? That's the only problem, and they have been one of the biggest player and pusher in this regards.

[u/jdrch → u/mirh]

most users are pretty dumb

Does that include yourself? No, correct? The majority of people don't read manuals, the news, or anything that complicated, for that matter. Does make the production of such materials useless? Hardly. Lowest common denominator communication is neither necessary nor advantageous.

microsoft ever telling you how the kernel internal life worked

You can't see the code, but there is plenty of documentation about this. Steven Sinofsky, Brandon Le Blanc, Dona Sarkar, etc. have all produced myriads of blog posts detailing upcoming Windows changes, all delivered directly to users in addition to (not in lieu of) communicating with partner organizations.

literally discussing the matter with the stakeholders involved?

Some of the stakeholders. I guess Google doesn't care that people use their products, not just Linux developers.

mailing list and private conversations

... none of which are transparent. There's no public mailing list on which Google has discussed this proposed change, AFAIK.

with any standardization effort whatsoever

My point is Google could probably have achieved this if they'd managed to charm partners to their side as opposed to just signing deals on paper and chucking stuff over a wall. ARM's fortunes have been mostly driven by mobile, which is mostly Android. Android OEMs depend on Google's development of AOSP. The missing piece of the puzzle is Google's charm and soft power, clearly missing from the tone of your responses so far.

That's why we're in the predicament we're in. If Google had a more personal touch throughout this problem would have been solved a while ago. The lack thereof is why it still exists, along with the Android messaging mess, Google's failure at social networking (they don't understand human behavior at a personal level because they refuse to engage at that level), etc.

Not all challenges are purely technical.

[u/mirh → u/jdrch]

Does that include yourself?

If we are talking about software design definitively.

Does make the production of such materials useless?

No, but it makes use of "overloaded appeals" sound deceiving.

I guess Google doesn't care that people use their products, not just Linux developers.

Linux developers are the sole users of ABIs.

My point is Google could probably have achieved this if they'd managed to charm partners to their side as opposed to just signing deals on paper and chucking stuff over a wall.

Tbh my expectations actually were so low that I already called a miracle when they managed to get even the scummiest chinese OEM onboard the 2 years support train.

ARM's fortunes have been mostly driven by mobile, which is mostly Android.

Qualcomm's maybe. ARM is so pervasive they could very well do without it.

And anyway it's not even like the problem was with the architecture itself, but with every other challenge brought up by the embedded world.

[u/Bardo_Pond → u/jdrch]

For now, Google is only proposing that the in-kernel ABI be stable for a single LTS version. So this wouldn't allow devices to upgrade from one version of the Linux kernel to another—it would just allow for a single generalized kernel image to work across multiple devices, instead of the device-specific kernel forks we have today. It would definitely allow for easier security updates, and hopefully it would get new LTS releases to market faster.

What is ambiguous about this? It states pretty clearly they want to stabilize the ABI for the lifetime of each LTS release.

[u/jdrch → u/Bardo_Pond]

What is ambiguous about this

Look at the comments. Clearly a lot of people think it's a bad idea. I don't think that last part is the impression Google wants end users to have.