The latest #LKML discussion about the #BPF extensible scheduler class (or "sched_ext") for the #Linux#kernel since yesterday is active again after a post from peterz:
"'That is, from where I am sitting I see $vendor mandate their $enterprise product needs their $BPF scheduler. At which point $vendor will have no incentive to ever contribute back.
[…]
[…] GPL forces people to contribute back […] And I see the whole BPF thing as a run-around on that. '" #LinuxKernel
"'In this post, I’ll describe our track record in supporting Linux on laptops with Windows on Snapdragon and how that continues with the Snapdragon X Elite. You’ll see what’s already merged in the mainline #Linux#Kernel, what’s pending and what’s on our roadmap.
@kernellogger If you want to describe that in the documentation:
Once you provided both a good and a bad version for git bisect, it will checkout automatically a commit in between. You don't have to test this commit: you may want to manually checkout a closer release tag, to avoid running into unrelated problems which got resolved after the merge window.
"'So Thorsten is still reporting a few regression fixes that haven't made it to me yet, but none of them look big or worrisome enough to delay the release for another week. […]
So 6.9 is now out, and last week has looked quite stable […]
And I now have a more powerful arm64 machine (thanks to Ampere), so the last week I've been doing almost as many arm64 builds as I have x86-64 […]
[…] obviously this means that tomorrow the merge window for 6.10 opens […]"'
If you just thought "But Linux already supports the #RaspberryPi5, see #RaspberryPiOS", then you just learned why differentiating between the #kernel called Linux (meant here) and operating systems called Linux (often build from forks of the former carrying modifications and enhancements) is important. #LinuxKernel
"'[…]
alpha: remove DECpc AXP150 (Jensen) support
alpha: sable: remove early machine support
alpha: remove LCA and APECS based machines
alpha: cabriolet: remove EV5 CPU support
alpha: drop pre-EV56 support
[…]
72 files changed, 166 insertions(+), 4545 deletions(-)'"
These changes from @arnd since today can be found in linux-next, too.
"'[…] is a filesystem centric mapping layer that maps file's logical offset ranges to physical extents. It provides several iterator APIs which filesystems can use for doing various file_operations, address_space_operations, vm_operations, inode_operations etc. It supports APIs for doing direct-io, buffered-io, lseek, dax-io, page-mkwrite, […]'"
@kernellogger Well, some of those 1000 have been rejected, here's the current stats that anyone can check for themselves in our public git repo by running scripts/summary so you don't have to hack up fun find | wc chains like you did:
Anything older than 2023 is us back-filling in from the GSD database, and we still have a long way to go for there. Some 2023 ones are in there too from GSD, but mostly not, all of 2024 is since we took over being a CNA.
@ljs@airlied@kees@kernellogger@gregkh a few stable kernels at most is the limit for backporting individual patches for drm. beyond that, it's just wishful thinking and yes, you're better off backprting the entire subsystem
@monsieuricon@kees@kernellogger@corbet@gregkh Thanks for the clarifications -- I guess there is a subtle (but significant) difference between "they're going to drop that back to just two years of support for the long-term stable releases" (literal quote) vs. "we start out at 2 and extend as needed" (paraphrased FAQ + parent toot).
You aren't alone, Linaro had a whole "webinar" about how the world is in trouble now that LTS releases are only 2 years, despite my objections directly to them that "this is not the case".
The recording of Linus Torvalds' (@torvalds) fireside chat with Dirk Hohndel (@dirkhh) recently held at the #OpenSourceSummit North America is now online:
'"[…] introduces preliminary support for a new reference storage backend called “reftable,” promising faster lookups, reads, and writes for repositories with any number of references. […]
Preliminary support for SHA-1 and SHA-256 interoperability
[…] git config learned a new option to help document your .gitconfig file […]"'
Hans de Goede writes: "'The firmware which drm/kms drivers need is becoming bigger and bigger and there is a push […]
This has made me think about dropping the GPU drivers from the initramfs and instead make plymouth work well/better with simpledrm (on top of efifb). A while ago I discussed making this change for Fedora with the Red Hat graphics team spoiler: For now nothing is going to change. […]'"