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

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

2/ Side note for users of #Fedora #Linux:

#LinuxKernel 6.12 is now available for all Fedora releases in the "stable" #copr of my #kernel vanilla repositories.

For install instructions, see https://copr.fedorainfracloud.org/coprs/g/kernel-vanilla/stable/ and https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories

In addition to the regular kernel package that copr as of today started shipping a dedicated #realtime kernel which has #PREEMPT_RT enabled. Install it by running:

$ sudo dnf install kernel-rt

#Linux 6.12 is out. For a list of new features see:

* This short LWN story: https://lwn.net/Articles/997958/ (screenshotted)

* Two detailed stories from LWN: https://lwn.net/Articles/990750/ & https://lwn.net/Articles/991301/

* The kernelnewbies page: https://kernelnewbies.org/Linux_6.12

See also the announcement from @torvalds:

https://lore.kernel.org/lkml/CAHk-=wgtGkHshfvaAe_O2ntnFBH3EprNk1juieLmjcF2HBwBgQ@mail.gmail.com/

'"No strange surprises this last week, so we're sticking to the regular release schedule, and that obviously means that the merge window opens tomorrow."'

#kernel #LinuxKernel

5/ TWIMC and for the record:

Werner Sembach from @tuxedocomputers *reverted* Uwe's changes that made the drivers provide the right license to the #Linux #kernel's MODULE_LICENSE()[1] macro "until the legal stuff is sorted out":

https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427

Wondering why that happened – did they only notice now that the drivers do not compile any more because they use GPL-onlyed symbols, which are inaccessible for any non-GPLv2-compatible module?

CC: @waldi

4/ TWIMC and for the record:

Werner Sembach from @tuxedocomputers now merged Uwe's proposed changes that make the drivers provide the right license to the #Linux #kernel's MODULE_LICENSE()[1] macro. 👏

https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/merge_requests/21#note_0294911d6ab1408f96fa73e062851920e16b4460

(side note: I suspect the kernel will now taint itself as "proprietary" when loading these drivers, but haven't tried)

CC: @waldi

6/ To follow up:

There are now patches under discussion upstream to '"teach the [#Linux #Kernel's] module loader that these modules [from @tuxedocomputers ] are proprietary despite their declaration to be GPLv2 compatible "until the legal stuff is sorted out". "'

https://lore.kernel.org/all/20241114103133.547032-4-ukleinek@kernel.org/t/#u

CC: @waldi #LinuxKernel

@gregkh @mxk

many thx for the insights! 👍

I sometimes wish I could follow what happens in the Android world more closely, but there are only so many hours in a week… 😟