LWN: Comments on "The 6.15 kernel has been released"

Bamboozled

jtepe — Sun, 08 Jun 2025 19:24:08 +0000

Thank you for some application examples for these new features.

Bamboozled

geofft — Wed, 28 May 2025 18:34:35 +0000

Fleshing out the pidfd API sounds like a good general-purpose thing. It's a slow fixing of the UNIX model to make one more thing a file. I don't think this is going to be immediately visible if you're using shell commands etc., but it does feel like in a couple of years, people writing systems code in C (etc.) are going to want to think in terms of pidfds instead of PIDs.

In the longer term, I guess you could imagine a version of top/ps/kill/etc. that operates on pidfds somehow, though I guess a question is where to store those pidfds if all of these are themselves independent processes is a question. (Will we see some limited REPL for interacting with processes, where the "top" subcommand holds onto pidfds, and the "kill" subcommand uses them?)

Guard pages for file mappings probably also won't show up at the shell level of abstraction, but being able to reliably catch small out-of-bounds reads of mmapped files seems cool and very visible at the C programming level of abstraction.

Nested idmapped mounts will be useful as soon as container managers start using them, in the sense that you'll be able to run a container manager using this feature in a container using this feature. It'll be visible in the sense that it's one fewer feature that will inexplicably fail in a nested-container setup. (Though I suppose there's a bunch of steps to get there like nested subuids, which is not necessarily a kernel thing so much as allocating a sufficient range to be able to nest inside it.)

Kernel-enforced FUSE timeouts seem incredibly useful for the subset of sysadmins who have to deal with complex FUSE applications, so much so that I paused writing this comment last night to go email a colleague about it. Many people probably won't notice, though.

I'm personally intrigued by the Apple Touch Bar support as the owner of a laptop with one of those, but I guess that too is a shrinking class of users. (That said, I'm not actually sure if I want to put Linux directly on my MacBook; everything I need to do professionally I can do in a VM, and the older I get, the less I want to sysadmin my personal machine non-professionally and the more I'm willing to trade off freedom and functionality for risk management.)

Scrub for bcachefs

farnz — Wed, 28 May 2025 08:47:14 +0000

For the US specifically, under the current rules, most radio transmitters will only be restricted by 47 CFR 15.12, which does match your version of 4, with the exception of U-NII devices, which have extra restrictions in 47 CFR 15.407(i).

However, historically the FCC took the position that unless a modification that breached the rules needed significant enough skill with a soldering iron that you could have built an equivalent device yourself (e.g. adding a transistor to the RF path or replacing a soldered down IC), they'd change the rules to retroactively prohibit any devices that were being modified to breach the rules. There's still remnants of this in the rules today; for example, 47 CFR 97.317 is intended to make it very hard to sell an amateur amplifier for 10m that can be easily modified for use with CB.

Scrub for bcachefs

johill — Wed, 28 May 2025 07:04:47 +0000

Also non-lawyer here, and really just going by what I've been told, which almost certainly is a very specific (local) interpretation, but:

It's not necessarily the biggest concern to prevent users from _intentionally_ doing such things on their individual devices assuming it would be difficult and/or obvious enough. You must, at least to some extent, also prevent said device users from being harmed by e.g. random exploit code running on their machines, and prevent anyone from being able to break things at scale. Understandably, the FCC cares less about a single user finding a way around limitations than a "script kiddie" breaking the regulations on millions of machines in some automated fashion, possibly even harming users in the process or even with the intent of doing so.

Taking this argument face value, I'd think that at that point you basically end up needing some kind of obvious switch like ChromeOS laptops have for their developer mode, but that's clearly not feasible for a random embedded radio (say WiFi or 5G modem.) I suppose it _might_ be doable for certain classes of expensive devices, but I'd think the extra development effort never pays off.

Scrub for bcachefs

pizza — Tue, 27 May 2025 23:11:24 +0000

> Chances are it is potentially violating patents, or it is unsafe as all heck. Likely both.

Neither; it's the old standby of a combination of "security" and "if we allow modifications we potentially become [strictly] liable under numerous federal laws"

Scrub for bcachefs

NYKevin — Tue, 27 May 2025 22:07:08 +0000

Unfortunately, this is or was a common pattern for anything with a radio transmitter in it. The usual argument goes like this:

1. We have a radio, so we must comply with FCC (or local equivalent) regulations.
2. The FCC (or local equivalent) says that our radio must do X or must not do Y.
3. It is physically possible for our radio to violate those rules.
4. Therefore, we must prevent users from doing anything with our radio unless we're sure it would comply with the rules.

As a non-lawyer, I'm not well positioned to assess whether that is a valid legal concern (there are at least ~200 jurisdictions in the world that might plausibly have different answers to that question). But in an ideal regime, (4) would look more like the following:

4. Therefore, we must clearly warn users that tampering with the radio may cause them to violate the rules, and get them to agree that we will not be held responsible for any violation of the rules caused by the user's modifications, even if our software or firmware contributed to the violation in some way.

Scrub for bcachefs

hmh — Tue, 27 May 2025 15:51:18 +0000

Chances are it is potentially violating patents, or it is unsafe as all heck. Likely both.

Scrub for bcachefs

pizza — Tue, 27 May 2025 13:46:02 +0000

> There is healthily growing hostility towards open hardware specifications and open source code among the vendors.

I'm dealing with a spec right now that *mandates* that it (and implementations) be kept confidential.

because $reasons

Scrub for bcachefs

parametricpoly — Tue, 27 May 2025 12:50:49 +0000

There is healthily growing hostility towards open hardware specifications and open source code among the vendors.

Bamboozled

khim — Tue, 27 May 2025 11:44:41 +0000

I think it's more of change in breadth rather than change in depth.

“Add quirk for Lenovo Yoga Pro 7 14ASP10” is still perfectly understandable description line… but chances are that you wouldn't care about it because you don't have Lenovo Yoga Pro 7 14ASP10!

In an era where Linux supported half-dozen of different configurations chances that any particular change would be relevant for your were much higher.

Bamboozled

magfr — Tue, 27 May 2025 03:40:31 +0000

I feel kind of the same.
There's also perf. I think it can be massively useful if I only could manage to wrap my head around it.

Bamboozled

motk — Tue, 27 May 2025 00:28:10 +0000

A lot of it is only relevant to the hyperscalers, tbh.

Bamboozled

coriordan — Mon, 26 May 2025 19:39:18 +0000

Haha, same. Release notes used to be "Good news, you don't have to recompile your kernel to get your sound driver working!!!"

I still take a look at kernel release notes sometimes, because I think I should keep a little bit up-to-date with what's happening in there, and I'm expecting to understand something, but I don't.

Scrub for bcachefs

koverstreet — Mon, 26 May 2025 16:08:56 +0000

Why? :)

People forget that filesystems are massive projects, these things do take awhile.

But it's been steadily coming along.

Bamboozled

pwfxq — Mon, 26 May 2025 12:37:40 +0000

Hardware is way more complicated compared to when *nix was first written. In the "good old days", most I/O was just writing bytes to the relavent I/O port (or memory address) and multi CPU systems were not in the hands of the home user. (let alone the whole conept of different capacity CPUs)

Scrub for bcachefs

kragil — Mon, 26 May 2025 10:47:08 +0000

So you have still hope that bcachefs will go anywhere? I've lost that quite recently tbh.

Scrub for bcachefs

ballombe — Mon, 26 May 2025 10:46:52 +0000

It is kinda nostalgic to see devices being supported Linux two years after being discontinued!

Bamboozled

alspnost — Mon, 26 May 2025 10:39:46 +0000

It's funny - in the old days, I could just about understand new kernel features and why they were cool and exciting, with each release. Nowadays, not a clue what any of this stuff means. In probably 27 years of following Linux, I suppose all the 'obvious' things have been done/re-done/re-done again, and we're now into the era of esoteric enhancements that are obviously good, but beyond the comprehension of ordinary sysadmin/infrastructure mortals like me!

internal compiler error

arekm — Mon, 26 May 2025 10:16:22 +0000

linux-6.15/security/landlock/fs.c:1745:61: internal compiler error: in count_type_elements, at expr.cc:7075
1745 | .u.op = &(struct lsm_ioctlop_audit) {

but

https://git.kernel.org/pub/scm/linux/kernel/git/kees/linu...

helped.

There is also failure:

linux-6.15/drivers/scsi/qedf/qedf_main.c:702:9: error: positional initialization of field in ‘struct’ declared with ‘designated_init’ attribute [-Werror=designated-init]
702 | {
| ^
linux-6.15/drivers/scsi/qedf/qedf_main.c:702:9: note: (near initialization for ‘qedf_cb_ops’)

Scrub for bcachefs

jmalcolm — Mon, 26 May 2025 07:43:46 +0000

Looking forward to scrub in bcachefs.

Also nice to see support for the Apple T2 chip as I have a couple of devices with that in them.