Notices by Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org)

"[…] Let's take a look at 6 improvements to look forward to in the upcoming #GCC 15.

1. Prettier execution paths

2. A new look for C++ template errors

3. Machine-readable diagnostics

4. An easier transition to C23

5. A revamped color scheme

6. libgdiagnostics

We're still fixing bugs, but we hope that GCC 15 will be ready to officially release (as 15.1) sometime later this month. […]"'

https://developers.redhat.com/articles/2025/04/10/6-usability-improvements-gcc-15 – by David Malcolm #gcc15

Christoph Hellwig, who recently vetoed dma-mapping #rust bindings, stepped down as maintainer for the dma-mapping[1] and configfs[2] subsystems of the #Linux #kernel.

[1] https://git.kernel.org/torvalds/c/f7d5db965f3e132887779c6b449452db2b807caa

[2] https://git.kernel.org/torvalds/c/815291c11acda54515f1af5ce6fe307490de9127

#LinuxKernel #Rustlang

2/ For the record:

* Christoph Hellwig might have dropped two #Linux #kernel maintainer positions (and a reviewer entry for VMALLOC), but kept four others, among them for the NVMe driver and the NVMe target driver: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n16933

* From a look at the lore archives it currently looks like hch is as busy as usual when it comes to contributing to the #LinuxKernel https://lore.kernel.org/all/?q=f%3A%22Christoph+Hellwig%22+d%3A2025-02-24..

Linus replied to Christoph about the Rust for #Linux DMA blockage:

https://lore.kernel.org/all/CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_R0Gwvg5kHrYr4Ko9dUHQ@mail.gmail.com/

'"Honestly, what you have been doing is basically saying "as a DMA maintainer I control what the DMA code is used for".

And that is not how *any* of this works […]

You are saying that you disagree with Rust - which is fine […]

I respect you technically, and I like working with you.

And no, I am not looking for yes-men, and I like it when you call me out on my bullshit. […]"'

#kernel #LinuxKernel

Linus on the social media shaming in the context of the #Rust on #Linux DMA drama[1]:

https://lore.kernel.org/all/CAHk-%3Dwi%3DZmP2%3DTmHsFSUGq8vUZAOWWSK1vrJarMaOhReDRQRYQ@mail.gmail.com/

"'[…] the current process works.

It has problems, but problems are a fact of life. There is no perfect.

However, I will say that the social media brigading just makes me not want to have anything at all to do with your approach.

[…] Technical patches and discussions matter. Social media brigading - no than\k you.

Linus"'

[1] https://fosstodon.org/@kernellogger/113955147394109633

#kernel #LinuxKernel #Rustlang

@ike there are many aspects at play here, but let me pick one that stuck out:

In a professional setting you work in the interest of the company for the money you get in return.

In FLOSS projects like Linux (the kernel) everyone is a volunteer with a different motivation. As project leader you don't want to step on people toes without strong needs too often (especially not those of core people), as that can quickly ruin a project. It's similar in sports clubs, rabbit breeders association, …

Linus on installing #rust support for #Linux development and 'allmodconfig' builds:

"'It really should be as simple as installing the proper distro packages […]. So do the pacman / apt / dnf / emerge / zypper command line to just install the packages […].

Of course, that assumes you have a modern enough distro that it _has_ sufficiently up-to-date rust packages.

So if you are on something like #Debian stable, it's simply not worth the pain."'

https://lore.kernel.org/lkml/CAHk-=wja7+gm-9s0-ba-FnykK2j0VWyNwOH7VzWSdMERWQzb_g@mail.gmail.com/

#kernel #rustlang

3k followers? Cool! 🥳 Glad you are all here! Enjoy your time in the Fediverse!

Never expected it to get the number that high when I came here a bit more than two years ago – and a few months later stopped tweeting using my Twitter account that had 5k followers back then.

Migrating away from #bcachefs

https://blog.sesse.net/blog/tech/2025-01-20-21-45_migrating_away_from_bcachefs.html

Steinar H. Gunderson aka Sesse writes:

'"[…] I've converted my last bcachefs filesystem to XFS, and I don't intend to look at it again in the near future. […]

I no longer trust bcachefs' future. […]

[…] I've had catastrophic data loss bugs that went unfixed for weeks despite multiple people reporting them. I've seen strange read performance issues. I've had oopses. […] “oh, yeah, that's a known issue […]

There are more things: […]"'

Imagine being a mechanic for Mercedes and receiving an email from a customer who complains about leaky doors and strange engine noises – and only after four or five tedious mails back and forth you figure out the car was bought from modder who added gullwing doors, shortened the wheelbase, and added twin turbochargers.

I guess that's how #Linux developers feel when they find out the bug someone reported only happens with a heavily modified #kernel like those shipped in RHEL, SLES, or Ubuntu.

#Linux Context Switching Internals: Part 1 - Process State and Memory

https://blog.codingconfessions.com/p/linux-context-switching-internals

Abhinav Upadhyay writes: '"How does the #LinuxKernel represent processes and their state: A breakdown of task_struct and mm_struct

At first glance, context switching seems straightforward—save the current process's registers, switch page tables and stacks, and restore the new process's registers.

However, the reality is much more complex, involving […]"' #kernel

The #LinuxKernel's stable team extended the support timeframe for #Linux 6.1 from four to five years:

https://www.kernel.org/releases.html

To quote @gregkh from https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=e6083565a79c3d711c1a76d9312b8c00e06b826b:

'" Bump 6.1.y support up to 5 years.

Giving people a chance to phase in the shorter lifespans, if at all possible. Hopefully this should help a bit.'"

#Kernel

2/ Regarding the #Linux 4.19.y EOL, see also this nice and interesting series farewell note from @gregkh:

https://lore.kernel.org/all/2024120520-mashing-facing-6776@gregkh/

'"[#LinuxKernel 4.19] had a good life, despite being born out of internal strife. […]

As a "fun" proof that this one is finished […] , I looked at the "unfixed" CVEs from this #kernel release. Currently it is a list 983 CVEs long, too long to list here. […]"'

Greg now officially deemed #Linux 6.12 as a longterm #kernel by adding it to https://www.kernel.org/category/releases.html right after marking 4.19 as EOL; ohh, and he marked the #LinuxKernel 6.11 series as EOL today, too!

For details see the latest commits here: https://git.kernel.org/pub/scm/docs/kernel/website.git/log/

3/ There is now a official msg from the #Linux Foundation Technical Advisory Board (TAB) to #Bcachefs developer Kent Overstreet based on a recommendation from the Code of Conduct Committee :

https://lore.kernel.org/all/6740fc3aabec0_5eb129497@dwillia2-xfh.jf.intel.com.notmuch/

'"[…] written abuse of another community member required action on your part to repair the damage to the individual and the community. You took insufficient action[…]

- Restrict participation in the kernel development process during the Linux 6.13 kernel […]"'

#kernel #LinuxKernel

And with "reiserfs: The last commit", #reiserfs is now gone from #Linux for 6.13:

https://git.kernel.org/torvalds/c/fb6f20ecb121cef4d7946f834a6ee867c4e21b4a

63 files changed, 12 insertions, 32804 deletions

Bye bye! 👋

#LinuxKernel #Kernel #FileSystem

@thelinuxEXP

BTW, to get an impression how to hard this stuff is with DKMS and how it easily it can fail for users, just look here: https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/issues/209

That's another reason why I would avoid using words like "Standard practice", as it gives the wrong impression to people that are not aware of these things. Not to mention that this license trick is hardly standard, as @Conan_Kudo already pointed out.

CC: @fabyk @tuxedocomputers

@thelinuxEXP

it's just a detail, but imagine how different the Linux world would look like if you for each machine where you install Arch/Debian/Fedora/… on would first have to hunt down a proper driver package from official or unofficial sources while praying on each kernel update that things do not fail because some API considered kernel-intenal changed and broke compilation with DKMS…

CC: @Conan_Kudo @fabyk @tuxedocomputers

2/ For completeness, as it's easy to miss in Kent's long post:

Kent refuses to send a public apology for a remark to a mm developer that lead to the escalation to the COC. Search for "you should probably send him an apology" in his Patreon post to find a good place to start.

Also note that Kent resurrected the #LKML thread with the remark yesterday; new messages start here: https://lore.kernel.org/all/vvulqfvftctokjzy3ookgmx2ja73uuekvby3xcc2quvptudw7e@7qj4gyaw2zfo/t/#u

Linus apparently will not pull any #Bcachefs changes into #Linux 6.13 due to "an open issue with the CoC (Code Of Conduct) board".

Kent shared that in a 36k long patreon post starting with "the future of bcachefs in the #kernel is uncertain, and lots of things aren't looking good.":

https://www.patreon.com/posts/116412665

Side note: this happened just hours after the rules for "Enforcement for Unacceptable Behavior Code of Conduct Violations" were merged to 6.13 :

https://git.kernel.org/torvalds/c/c818d5c64c9a8cc14853d716bf7ce6674a6126d0

#LinuxKernel