@kernellogger @mxk Totally understand.

Here's a link to Todd's latest Plumbers conference calling out how they are going to support devices for 7+ years by moving to new kernel versions over time: https://lpc.events/event/18/contributions/1703/attachments/1391/2998/LPC%202024%20-%20Android%20Device%20Longevity.pdf

@kernellogger @mxk That's not how Android kernels are working anymore. Vendors can have huge numbers of external kernel drivers/modules (i.e. pixel 6 has 300+ of them), but the "core" kernel is managed by Android/Google, in public, in their GKI kernel branches, and that is what is the "base" of the kernel that all vendors can then add drivers to.

If a vendor wants to change the "core" parts of the kernel, they must either submit the changes upstream for merging first (and then backport the change to the GKI kernel and submit it to Android), or somehow convince Android to take it into their GKI kernel (with reasons why upstream rejected it), or add a "hook" to the GKI kernel so that they can put their changes in a kernel module (like many do for scheduler changes.)

The -lts releases get merged into the Android/GKI kernel branches on a monthly basis, which then gets pushed out to all devices "quickly" as there are no in-kernel-abi breaks between the GKI kernel and all external kernel modules used by vendors.

Android has followed the "old" enterprise kernel module here, with the exception of the hook additions, that companies have used for decades (the abi stability changes were taken directly from RHEL and SLES). It's not exciting kernel work, but allows security fixes to get pushed out to devices MUCH faster which is helping everyone out, AND it has forced the vendors to work upstream to get their features merged properly, which has been happening for years now to much success.

There was a plumbers talk all about this this year (and last, and the year before), if you want more details.

@tusooa Heh, you're trying to convince a "Russian identified person" in one of the senior positions in the Linux Foundation that the Linux Foundation is being unfair towards "Russian identified people." It's pretty hilarious.

I'm not a lawyer and I don't speak for the LF, so I won't give you any kind of "official comment." But here's my view of it.

The people removed from maintainer positions were identified as employed by companies on the US and EU sanctions list. These companies are directly involved in the Russian military complex and therefore are directly complicit in war crimes being committed daily in Ukraine. If these maintainers want to think that they are "just techies helping improve the Linux kernel," or that "they are outside of politics," then they are fucking wrong. If they work for companies that develop weaponry or logistics used by the Russian military, they are complicit in Russia's war crimes, and I hold them responsible at a very personal level -- and that's my official comment on the situation.

#usbutils (which contains lsusb and the more modern lsusb.py) 018 is out:

https://lore.kernel.org/all/Zxd0oZefuehqhA7z@kroah.com/

@gregkh writes:

'"For users, the largest change will be that the '-v' option to lsusb will now show the negoitated speed of the device on the bus […], and there is better handling for new device descriptor fields and information in the '-v' output as well."'

@kernellogger And that is why the AUTOSEL bot exists.

@kernellogger NP, and odd that no one actually tagged that commit to be backported to stable kernels... {sigh}

Then here came @gregkh talk about CVE and Rust (see 39:42):

"Rust is going to help us. It'll fix up all the error handling bugs. When you do bad things in memory it just reboots the box... You will get CVE but you won't be able to make a vulnerability out of it."

https://youtu.be/bf3MYWtI4E4?feature=shared

@kernellogger I'll go pick it up for stable/LTS trees now, don't worry :)

For open source people, I recommend reading this fine post from @nlnetlabs / @maarten -> https://blog.nlnetlabs.nl/what-i-learned-in-brussels-the-cyber-resilience-act/ and you might also get some benefit from https://berthub.eu/articles/posts/eu-cra-recitals-comments-compiler-judge/ if you plan on reading the actual act -> https://data.consilium.europa.eu/doc/document/PE-100-2023-INIT/en/pdf 2/2

So… O’Reilly sent me email today hyping up how my books (really, just the one, I assume) is going to be AI-translated into Spanish and German, with other languages to follow. This was probably inevitable, but I still have concerns.

First: are there no human translators of these languages?

Second: who’s going to proof-read all 1,126 pages to make sure nothing got botched, especially given the technical nature of the content? The readers? Which isn’t even crowd-sourcing: it’s customer-sourcing.

@hikari What firmware blobs? The old ones were all in text format anyway (arrays of bytes in a .c or .h file), so that's never really been an issue. I think they are almost all gone from the tree now so that shouldn't be an issue.

For the linux-firmware project, you can send binary diffs to them, in email, git handles that just fine. You aren't reviewing a binary file anyway, it's either you take it or you don't.

@hikari @mcepl @koopa Linux doesn't have binary files in its source tree (for the most part, there are a few tiny exceptions), so this isn't an issue at all.

@hikari @mcepl @koopa Agreed, and for smaller projects, gerrit is almost even nice to use, but for ones with any "real" amount of size of developers and rate of change, it is rough and I curse it every time I have to review a kernel patch series in the Android gerrit instance :)

@hikari @mcepl @koopa "well" is "better than any other web-based workflow" yes, gerrit does handle them better that way.

But no way is it better than an email-based review workflow, whereby I can just tear through hundreds of patches in a very short amount of time, all while sitting behind a very slow/laggy internet connection, or totally disconnected (i.e. better for distraction-free work).

As almost no other project is at the rate of change or size of the Linux kernel, gerrit might be wonderful for your smaller one. But for ones that are our size, realize that centralized workflows like gerrit and the like just do not scale at all.

@ljs @axboe @kernellogger @oleksandr @vbabka That is EXACTLY why AUTOSEL is being used, for subsystems and maintainers and developers who forget to tag their fixes for stable. If everyone was perfect, and all always followed the process without any mistakes, it would not be needed at all.

Also remember that we still have areas of the kernel where subsystem maintainers and developers refuse to add any cc: stable tags, or anything else to give us a hint as to what should be backported, which is why AUTOSEL was created in the first place.

Heck, AUTOSEL catches things _I_ missed for my subsystems and forgot to tag for stable, I want it enabled for my subsystems for that reason alone. A quick glance once a week at what patches I was cc:ed on to verify they were correct is a trivial thing overall.

And as always, if you do NOT want your subsystem to be picked up for either "Fixes:" or AUTOSEL work, just let us know and we will instantly add you to our ignore list as seen here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/ignore_list

Every language has an optimization operator. In C++ that operator is //'

Gotta say, if an unknown new printer shows up in my print dialog, my first thought won't be "cool, let's try printing to it."

In systemd we started to do more and more Varlink IPC (instead of or 9n addition to D-Bus), and you might wonder what that is all about. In this AllSystemsGo talk I try to explain things a bit, enjoy: https://media.ccc.de/v/all-systems-go-2024-276-varlink-now-

@brauner from the "rumors" floating around at the last conference I was just at, userspace.

From @gregkh : Rust is going to help us with [CVEs in the Linux Kernel] by eliminating some bug classes.

#RustLang #kr2024