Conversation

Notices

1. Embed this notice
   lj·rk (ljrk@todon.eu)'s status on Tuesday, 27-Feb-2024 14:54:51 JST lj·rk

   • Greg K-H
   • kurtseifried (he/him)
   • Josh Bressers

   @kurtseifried @gregkh @joshbressers This does increase pressure on the Kernel APIs to be more stable however. While "don't break user space" is a mantra, this will get tested much more in the future, systems running ages old glibc on a current stable kernel... . Also, let's see how proprietary kernel drivers do.

   I'm all for it!

   • Embed this notice
     Greg K-H (gregkh@social.kernel.org)'s status on Tuesday, 27-Feb-2024 14:54:46 JST Greg K-H

     in reply to

     • kurtseifried (he/him)
     • Josh Bressers
     @ljrk @joshbressers @kurtseifried The core Android portion of Google is very much NOT out-of-tree, they merge their code upstream almost always first before applying it to older Android kernel branches. See the yearly report at the Linux Plumbers conference for the past 5+ years where they what has been merged, what is left to be merged, and what is coming next, with pretty graphs and the like.
     They have a strong "Get your changes upstream first" rule with their OEMs and you can see the interactions with those companies uptream has increased dramatically over the past years been because of this.
     
     ChromeOS portion of Google also has a strong "upstream first" rule, and is very good about taking updates and getting changes merged properly.
     
     The Pixel out-of-tree stuff is due to other "reasons", but that is a separate division and there have been many patch submissions recently upstream to resolve that delta, so that is being whittled down.
     Haelwenn /элвэн/ :triskell:, clacke and James Morris like this.
   • Embed this notice
     Greg K-H (gregkh@social.kernel.org)'s status on Tuesday, 27-Feb-2024 14:54:48 JST Greg K-H

     in reply to

     • kurtseifried (he/him)
     • Josh Bressers
     @ljrk @joshbressers @kurtseifried Based on the Android work I've seen happening, I doubt it. We have successfully run Pixel6 on every Linus -rc release for the past 3 years and that had 300+ out of tree drivers, not an issue. If you want to keep your code out of tree, you can, it just costs you money to do so, which companies have long understood for many decades now, it's their business decision. CVEs aren't going to change this at all, it does not affect the rate-of-change of upstream and stable releases at all.
   • Embed this notice
     lj·rk (ljrk@todon.eu)'s status on Tuesday, 27-Feb-2024 14:54:48 JST lj·rk

     in reply to

     • Greg K-H
     • kurtseifried (he/him)
     • Josh Bressers

     @gregkh @joshbressers @kurtseifried While I’ve followed the Android work quite closely and that’s one of the reason I’m using a Pixel, Google is much different w.r.t. company culture than many other companies that I had in mind when writing this. Against all technical reasons they insist on staying out-of-tree. And I suspect that some of them will maybe use that development (i.e., working “against” back porting) to move in-tree too — but those who remain will do so more fiercely.

     Do note, that this is nothing I defend — I basically want them to go in-tree-or-die :’D

   • Embed this notice
     lj·rk (ljrk@todon.eu)'s status on Tuesday, 27-Feb-2024 14:54:49 JST lj·rk

     in reply to

     • Greg K-H
     • kurtseifried (he/him)
     • Josh Bressers

     @gregkh @joshbressers @kurtseifried Oh, I’m aware of that! It’s just that I suspect a) companies doing proprietary or at least out-of-tree-drivers will exert more pressure to become in-kernel-stable, a pressure Linux must, and probably will resist against though; and b) the current user space API stability will be put to a more thorough test.

   • Embed this notice
     Greg K-H (gregkh@social.kernel.org)'s status on Tuesday, 27-Feb-2024 14:54:50 JST Greg K-H

     in reply to

     • kurtseifried (he/him)
     • Josh Bressers
     @ljrk @kurtseifried @joshbressers It does not affect anything at all about in-kernel apis, there is no such stability rules or requirements, rather the opposite.
   • Embed this notice
     clacke (clacke@libranet.de)'s status on Friday, 01-Mar-2024 21:44:14 JST clacke

     in reply to

     • Greg K-H
     • kurtseifried (he/him)
     • Josh Bressers

     @gregkh @ljrk If I remember correctly there is a huge difference between 2014 and 2024, where Android Linuxes like in Android 2, 3 and 4 had not only drivers out of tree, but their own subsystems and features, some of which had no chance of going upstream, because mainline had similar but different mechanisms.

     Some time between then and now some people started working hard on upstreaming what could be upstreamed and leaving behind things that couldn't, so that Android today can run on a mainline Linux, and anything out of tree is device-specific stuff.

     Is that a somewhat accurate overview?

     @kurtseifried @joshbressers

   • Embed this notice
     Greg K-H (gregkh@social.kernel.org)'s status on Friday, 01-Mar-2024 21:58:10 JST Greg K-H

     in reply to

     • clacke
     • kurtseifried (he/him)
     • Josh Bressers
     @clacke @joshbressers @kurtseifried @ljrk Yes, that is a good overview, and you can point at the managers and developers on the Google Android team for doing all of this hard work both in convincing people that this was a good idea, and actually doing the work to get stuff merged properly. I've watched them do this for the past 10+ years, it wasn't easy but has paid off a lot in my opinion, the security level of an Android device is worlds better than it used to be because of this effort.
     Haelwenn /элвэн/ :triskell: and clacke like this.