[HN Gopher] Linux 6.16: faster file systems, improved confidenti...
___________________________________________________________________
Linux 6.16: faster file systems, improved confidential memory, more
Rust support
Author : CrankyBear
Score : 114 points
Date : 2025-07-29 18:09 UTC (4 hours ago)
(HTM) web link (www.zdnet.com)
(TXT) w3m dump (www.zdnet.com)
| tombert wrote:
| I'm still kind of surprised that Linus ended up allowing Rust
| into the kernel. Good, but surprising.
|
| Looking forward to this release once it hits NixOS Unstable.
| xeonmc wrote:
| A surprise, to be sure, but a welcome one.
| Alupis wrote:
| My understanding is its contained to the "edges", mostly in
| drivers and not in the "core" kernel.
|
| Still interesting indeed.
| preisschild wrote:
| for now, due to gcc-rs not being completed yet and the rustc
| compiler not supporting every linux architecture
| dralley wrote:
| There's two gcc-based compilers for Rust, gcc-rs which is
| part of the gcc suite and written in C++, and
| rustc_codegen_gcc, which is an optional backend for the
| existing Rust compiler written in Rust which emits an
| intermediate representation that GCC can understand.
| rustc_codegen_gcc is much closer to completion.
| lights0123 wrote:
| It surprised me that Linux 6.12's QR code generator is
| written in Rust and enabled in at least Arch and Fedora.
| jeffbee wrote:
| Why does the kernel need a QR code generator?
| lights0123 wrote:
| https://www.phoronix.com/news/Linux-6.12-DRM-Panic-QR-
| Code
| infogulch wrote:
| Oh that's pretty nifty. It's always been a pita to get
| data (logs, traces, metadata etc) off of a crashed
| system. This is less human readable, but any human that
| wants to read it will want the raw data anyway. Way
| easier to do this than try to run photos of a screen
| through OCR.
| Twirrim wrote:
| A QR code can capture 3k of data, you can capture a lot
| of context and details in that, particularly if you apply
| a little bit of compression (and the kernel has
| compression algorithms embedded in it). More than can be
| captured on a screen normally, without it zooming out of
| sight.
| 6SixTy wrote:
| Would most people rather have a cell phone picture of the
| screen for debug logs, or a QR code that has those logs
| ready to be scanned and copy/pasted?
| geodel wrote:
| On that note seems like after ruckus about Hector Martin's PRs
| not getting merged, things are calm but progressing.
| dralley wrote:
| Linus is pragmatic. His only hard rule is "don't break
| userspace", most everything else is contingent.
|
| From what I can tell, he views Rust for Linux as a social
| project as much as a technical one - attract new (and younger)
| developers into the kernel, which has become pretty "senior",
| force all of the "unwritten rules" to be written down, and
| break down some of the knowledge siloing and fiefdom behavior
| that has taken place over the years (by sharing it specifically
| with that younger group of developers).
|
| If you think about it, Rust for Linux is in some ways
| essentially an auditing committee reviewing all of the API
| interactions between kernel subsystems and forcing them to be
| properly defined and documented. Even if the Rust part were to
| fail (exceedingly unlikely at this point), it's a useful
| endeavour in those other respects.
|
| But of course, if Rust is successful at encoding all of those
| rules using the type system, that unlocks a lot of value in the
| kernel too. Most of the kernel code is in drivers, and it's
| typically written by less experienced kernel developers while
| being harder to review by maintainers that don't have
| background on or access to the hardware. So if you can get
| drivers written in Rust with APIs that are harder to misuse,
| that takes a big load off the maintainers.
| tombert wrote:
| I just remember how much shit he talked about C++, and I
| guess I assumed that that would carry over to Rust as well.
| kstrauser wrote:
| True, but the Rust language itself is tiny compared to C++.
| There are only a slim fraction of the edge cases to learn.
|
| Note that I'm not saying Rust is easy to learn. I found it
| to be so, but it's going to be different for everyone. I do
| firmly believe that it's far easier for the average dev to
| learn the core of Rust than the core of C++, with far fewer
| footguns along that path.
| tombert wrote:
| Oh I don't disagree with any of that, I like Rust. I was
| just surprised is all.
| jcranmer wrote:
| From my memory of Linus's C++ comments, they basically boil
| down to "the kernel needs to do everything in freestanding
| mode, and everything that's interesting in C++ is not in
| freestanding mode, so what good is it?" (plus some ranting
| about "zero-cost" exception handling being rather more
| expensive than its name implies). In general, a strong vibe
| of someone who tried C++ in the early 90s, gave up on it
| then, and is generally ignorant of how C++ is different
| from back then.
|
| If Linus's first introduction to C++ was to C++11, I'd
| imagine his opinion of C++ would be higher (probably not
| high enough to permit it into the kernel, though). To a
| large degree, Rust is "take the good new parts of C++11,
| strip out some of the legacy insanity, and let's also work
| out how to keep as much of the good stuff in a freestanding
| environment as possible." Which answers a lot of the
| objections that Linus had to C++!
| Teknoman117 wrote:
| That's also in line with my memory of it.
|
| We _still_ don 't have all of the interesting C++
| features in freestanding mode. It's still a fairly
| unknown component of libc++ and libstdc++. I've only been
| playing with it recently because I was curious about how
| many of the c++17 and newer compile time features I could
| get to work in avr-g++.
|
| And the answer is ... not much.
|
| I've been spoiled by Rust's "core" crate.
| terandle wrote:
| Seems like Linus should be able to tap someone else to do 6.17
| while he is on vacation
| arp242 wrote:
| _> If your Linux laptop doubles as a music player, another nice
| new feature is that you can now stream your audio over USB even
| while the rest of your system is asleep. That capability 's been
| available in Android for a while, but now it's part of mainline
| Linux._
|
| How does that work? You still need some program to actually play
| the music (mpv, Sotify, whatnot)? Or what am I misunderstanding?
| Unfortunately there are no details in the article, and an
| interwebz search doesn't really show anything.
| RS-232 wrote:
| Maybe it's using Wake-on-LAN where the network interface is
| alive while the rest of the system is dormant? Perhaps the
| music stream is encoded in magic packets?
| arp242 wrote:
| I found [1], which says _" For Qualcomm hardware where the
| USB audio can be offloaded to a dedicated audio DSP for
| handling the transfers to the USB host controller, this
| lessens the work of the main CPU cores and can help with
| power management so those CPU cores can hit lower power
| states or tackle other work. Other hardware vendors will
| hopefully follow suit in their support for the upstream
| support around USB audio offloading."_
|
| So I think that it doesn't do anything for the average Linux
| laptop, and is mostly intended for certain (mobile) hardware?
|
| [1]: https://www.phoronix.com/news/Linux-6.16-USB-Audio-
| Offload
| smashed wrote:
| It's probably related to this:
|
| https://www.phoronix.com/news/Linux-6.16-QCOM-USB-Audio-OLOA...
|
| Audio usb offloading. Only supported on Qualcomm soc's.
|
| Article is misleading. Audio offloading is probably only useful
| to avoid waking the main CPU too often, so better battery
| management... CPU can remain sleeping a few microseconds
| longer, not all the time.
|
| Not something many will benefit.
| ndriscoll wrote:
| A 20 MB 3.5 minute .flac file takes ~200 ms to decode into a 35
| MB .wav on my desktop, so in principle the program could spend
| a small fraction of a second placing the decoded audio into a
| small buffer and give a pointer to hardware to keep playing it
| while the rest of the system goes to sleep for a few minutes.
| Or if the hardware has direct support for the codec, it could
| just give it the file as-is.
| barchar wrote:
| It probably requires active standby/s0ix. Modern Intel chips
| actually don't officially support s3 at all anymore, only s0ix.
|
| The whole point is to support stuff like this
| mschuster91 wrote:
| > If your Linux laptop doubles as a music player, another nice
| new feature is that you can now stream your audio over USB even
| while the rest of your system is asleep. That capability's been
| available in Android for a while, but now it's part of mainline
| Linux.
|
| I thought Android did that by just turning off all but one CPU
| core and suspend all processes not required for streaming +
| bluetooth?
|
| I really can't imagine how else that would work, other than
| essentially giving the whole audio file to the Bluetooth chip and
| let it handle streaming on its own... but I've never heard of a
| Bluetooth chipset capable of that, much less bluez actually being
| usable enough.
| techjamie wrote:
| Since sleep suspends execution and keeps the RAM state, I
| suppose it isn't a huge stretch for the kernel to provide some
| mechanism by which a program can stay awake while execution of
| others is paused.
|
| I'm sure there are aspects that are hard to reason about which
| I'm simply unaware of, but the idea makes sense to me.
| cestith wrote:
| It hands it off to a dedicated media playback DSP. Right now,
| only Qualcomm is supported but there's hope that now that the
| mainline kernel supports it other hardware providers will offer
| a way the kernel can do that for them, too.
| ElijahLynn wrote:
| The article mentions Linux pull requests. Does Linux contribution
| do actual pull requests now? Or is it still a mailing list?
|
| If the latter, why would they say pull request?
| justincormack wrote:
| Its a terrible article.
| 5kg wrote:
| It's subsystem maintainers asking Linus to pull from their
| branches, e.g. https://lkml.org/lkml/2025/7/29/291
| tux3 wrote:
| Pull requests took their name from the git request-pull script
| (which actually predates Github by a couple years):
| https://github.com/git/git/commit/ab421d2c7886341c246544bc8d...
|
| It is called a pull request because you are asking someone to
| do a `git pull` from your branch.
| PhilipRoman wrote:
| "Pull requests" can also be done via a mailing list (it's
| literally a request to pull from some URL, see git-request-
| pull). It is not common on LKML, but I've seen it used that
| way. I think it's mostly maintainers that use it among
| themselves, everyone else just mails patches.
| jauntywundrkind wrote:
| Neat to see zero-copy networking get TX, after RX shipped a while
| ago. Good stuff. I wonder how it overlaps-with/interacts with the
| various kernel offloads? I forget if this is TCP only or UDP too:
| would be really nice with QUIC / HTTP3 to see more love for UDP.
| https://www.phoronix.com/news/Device-Memory-TCP-TX-Linux-6.1...
|
| The filesystem Folio work has been yielding such amazing results.
| In general I'm just so impressed how much the storage subsystems
| keep improving! IO_Uring has totally changed the game in terms of
| iops delivered just on it's own. But then the various filesystems
| & upper level multi-queue support have also been consistently
| finding really nice wins. Folios have been incredible!
| https://lwn.net/Articles/1015320/
|
| EROFS added compressed metadata support, which is showing a 2.5X
| win for readdir(3) (reading files from a directory). Given it's
| use in awesome works like composefs for next-gen & content-
| addressed based container overlay type systems, this is a nice
| win. https://github.com/composefs/composefs
|
| Probably my favorite new feature is AMDGPU user queue (userq)
| work. Rather than the driver having to build out all the future
| work, now userspace can directly build the work of stuff to be
| done, sprinkling in various fences and what not. Some very
| interesting potential for GPGPU & perhaps ML!
| https://www.phoronix.com/news/Mesa-25.2-High-Priority-USERQ
| https://www.phoronix.com/news/Linux-6.16-AMDGPU-User-Queues
|
| The Kernel Newbies release log is one of my favorite things to
| read through. It wasn't bursting-at-the-seams with awesome as you
| sometimes get with releases, but 6.16 was still very fun.
| https://news.ycombinator.com/item?id=44717122
| https://kernelnewbies.org/Linux_6.16
| bpbp-mango wrote:
| > Perhaps the most popular Linux file system, Ext4, is also
| getting many improvements. These boosts include faster commit
| paths, large folio support, and atomic multi-fsblock writes for
| bigalloc filesystems. What these improvements mean, if you're not
| a file-system nerd, is that we should see speedups of up to 37%
| for sequential I/O workloads.
|
| nice to see ext4 still getting improvements
___________________________________________________________________
(page generated 2025-07-29 23:00 UTC)