This reporting feels a bit slanted. The author implies the big blockers are human beings; specific people & interactions he's called out for seemingly stalling the project.
Personally, I'm curious if there's hard technical blockers. Like, if there's features that Linux (or Rust) needs which could incur a serious burden that no team can sustainably maintain. That kind of reporting— deep insights into technical trade-offs— would be much more interesting than a play-by-play of drama.
The uncharitable take is that it's just job protection. That is current maintainer doesn't want to be replaced with some new Rust-writing folks.
A more charitable take is that the current maintainer is worried not about extra work now, but later when more things use Rust.
For example, say the Rust changes were merged and maintained by RfL folks. Then say NVIDIA replaces their current GPU drivers with a new Rust-based drivers.
Later a change to the DMA layer kernel code breaks the Rust code in a way that's not trivially fixable, and with that no NVIDIA GPU drivers.
Would the DMA changes still be allowed to be merged without any additional work by the current DMA layer maintainer?
This seems like something that could happen down the line, if the RfL project continues.
> That is current maintainer doesn't want to be replaced with some new Rust-writing folks.
Almost anyone paying Christoph is not doing so because of his involvement in the DMA subsystem - he's got a sufficiently strong involvement in any number of core parts of the kernel that if he dropped all involvement in DMA he'd still have enough employment opportunities to spend as much of his time skiing as he wanted.
> Personally, I'm curious if there's hard technical blockers.
That LWN or the kernel devs are keeping secret? I would be amazed why, if Christoph Hellwig had technical blockers, he wouldn't raise them in the LKML, right now, of all times.
Personally, I'm curious if there's hard technical blockers. Like, if there's features that Linux (or Rust) needs which could incur a serious burden that no team can sustainably maintain. That kind of reporting— deep insights into technical trade-offs— would be much more interesting than a play-by-play of drama.
On a side note, there's one paper on Rust in Linux that's been recommended but I've not seen it deeply discussed yet https://www.usenix.org/conference/atc24/presentation/li-hong...