It’s amazing to me how much reality show level entertainment we get out of Linux kernel discussions. Most of us don’t have a dog in the fight, yet it’s still engaging content to watch someone else’s drama and “workplace politics” play out .
a good number of us are users of the Linux kernel so we should have a dog in this fight. So this DMA guy gets mad and start introducing junk into the code and nobody catches it, who get hurt? I hope he just steps away; it'll be better for his sanity.
Linus said that he like to work with guy and respect him technically, the DMA is stable because of him, just because one day the guy step over his fence he should be removed?, how many maintainers did something similar in 20 years?, honestly this drama is overblown by people who never saw drama in the kernel and think that rust is the first and only big change that got maintainers reluctant to merge, RT took 20 years, Rust has a lot more devs, companies and investment behind
The drama came from Hector getting fed up with being stymied by Christoph overstepping his authority, trying to go around the system by starting a social media flame war, and eventually quitting.
This is how shit gets done in the real world (pretty much anywhere) when many people are involved. So yeah, it is reality in that regard.
I actually think Linus has had some of his rough edges smoothed out over the years. This was not nearly as combative as it could have been or may have been in the past!
Good to see Linus step up and publicly support Rust again. I was worried the drama might make he retreat and abandon the experiment.
Discussion started on neighbor thread: https://news.ycombinator.com/item?id=43123391
So if I understand correctly, Linus & co say no maintainer is forced to write or accept Rust code in their little piece of the kernel.
But maintainers claim that other people simply interfacing with their code through Rust bindings would require the maintainers to change that Rust code anyway if any changes they make would break those bindings? Am I getting that right?
The maintainer of the DMA subsystem, Christoph Hellwig seems to vehemently oppose having an mixed-language codebase, and is using the confusion whether he as a maintainer has a say against the consumers of his APIs, to further his cause.
There was indeed some confusion about this, because the normal rule of kernel development is that if you change an API, you also fix the downstream users. (A standard-ish monorepo rule.)
However, because R4L is an experiment, the rule seems to be different: it's up to the R4L team to fix the Rust side if things break, so the upstream C devs don't need to care about Rust if they don't want to. (And conversely, they can't then weaponize their reluctance against Rust. That blade cuts both ways!)
However, apparently there wasn't sufficient clarity about this rule. Well, now there is.
logistically, how would this work in a monorepo? if you merge an API change and don't fix downstream users, isn't the build broken for everyone? or is there a deprecation process where the old API remains functional for a period?
Rust is behind a flag that defaults off, so it's only broken for people who flip the flag.
Specifically, the reason Linus is lashing out here is that devs are claiming they want nothing to do with Rust, and then suggesting that that means they get to say Rust can't call their code.
e.g. what they really are doing, as Christoph explicitly admitted in the thread, is that they are attempting to relitigate whether you can use Rust at all in Linux, and convince people that it's so hard to work on that they just give up and go home.
In the end, for kernel users, yes. However, what he did is much larger IMHO: he addressed the utter blockade performed by the maintainer, that basically said no without any margin of negotiation.
In the end, he explicited that not wanting to touch Rust goes both ways: you don't want to touch Rust? Fine. But you lose all rights to complain about what others are doing with Rust.
In other words: don't be a jerk, and don't have selective involvement.
No, Linus is saying that to have a say, you have to stake something. You can't veto something and at the same time not engaging with it in any other constructive way. You either ignore it totally, or you don't and become part of the process. In this specific case, you do not get to decide who the client of your code/subsystem is, and the only way you have a say about it is by offering actual feedback about it.
I don't think that's true though, given the Linux development model where all internal APIs are private and unstable and can be changed at any time. It means there is a two-way dependency between API providers and users - because it isn't a public API you are allowed to change it, but you have to fix all the places it is used too.
If those places now include Rust then it would require you to learn Rust (or depend on other people).
Really they just need to make a decision at this point. Either Rust is allowed and maintainers are going to have to learn it, or there's no point and the Rust people are going to have to fork Linux.
I guess there is a third option: a stable driver ABI. But they've avoided that at all costs for years so I don't see it happening. And besides, Rust is going to be used for more than just drivers eventually.
> Really they just need to make a decision at this point.
They already _have_ made this decision. Why do people keep misunderstanding this. While ordinarily if you change the API you are required to change all of the callers of that API to match, in this one special case the maintainer of a module can declare that they don’t want to touch the Rust code and that if they change the API then they are not going to change the Rust code that calls it. In that case the Rust for Linux team will step in and make whatever changes to the Rust code are needed.
> I don't think that's true though, given the Linux development model where all internal APIs are private and unstable and can be changed at any time
Others have pointed out that this is mistaken, but also, it's in the link itself:
> So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't have to deal with Rust.
The argument being made was that the nominal rule is that the Rust side has to fix their things if the C side breaks them, but in practice it doesn't work that way, allegedly because Linus has NAKed patchsets that didn't have fixes for Rust being broken in them.
I would imagine the hopefully straightforward path would be to make sure the Rust code gets build tested, and then if that fails, have a route to reach out to the people who want to do R4L work and tell them "this is breaking because of what I changed, can you help when you get a chance", for the maintainers who don't want to learn Rust.
...of course, one reason the maintainers loathe this idea, is that the personality archetype who works on Linux generally is the kind of person who would go fix it themselves because they're impatient, so with that framing, it's pretty clear why they think "wait on other people to fix it" is a nonstarter de facto...
> So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't have to deal with Rust.
- Linus
I wonder why the delay in Linus' reaction. Could it be that he hoped a hands off approuch would let the people involved find a compromise themselves? Or is it just normal that he is unavailable for a few days.
In any position of real leadership, unless you have exigent circumstances that dictate otherwise, you want to lead, not dictate.
In that sense, there's real value in letting a situation develop its own consensus as the actors involved communicate and complete discovery of the factors and motivators involved in any situation, especially if it's clear that the actors have yet to explore that space.
He does open with:
> I was hopeful, and I've tried to just see if this long thread results in anything constructive, but this seems to be going backwards (or at least not forwards).
So probably just hoping some people on either side of the issue would see the light. But he also probably shouldn't have chimed in earlier then.
This is quite a reasonable policy and I wish it had been clearer to everyone earlier.
I'm the average rust fanboy, but DMA is something I would rather do in C, as there would probably be more line of unsafe rust code than safe...
Even unsafe rust is safer than C. Error management, type safety, modern language, etc. There are many reasons to use Rust in place of C, even if your whole code is one giant unsafe blob.
I run eBPF code written in Rust in production, and oh boy how more readable it is compared to C. Even simple stuff like `if let Some`, actual sum types, generics, are enough to warrant using Rust over C. And its endtrypoint is basically unsafe { ... }.
Don't mislead people like this. If you are writing C, oh well. If you are writing big unsafe Rust blocks, genuinely, you are holding it wrong. Rust's strength is that unsafe blocks are minimal and well-isolated, giving both the flexibility and performance of C and the assurances of safe Rust. The default is safe Rust and unsafe authors must ensure their code works when it is eventually contacted by safe Rust. That's why we can say Rust is memory-safe, like Java or C#, even though unsafe is a clearly advertised feature. Unsafe Rust is, at best, on par with C. Nice language features do not fix UB. If you're not taking advantage of safe Rust, you lose the benefits of using unsafe Rust. Rust's main innovation is the borrow checker; use it!
In the specific case where I'm using Rust, unsafe is definitely better. I mostly write eBPF XDP programs for where I write unsafe code.
So yes I agree that I don't get safety benefits. However, it does not mean I don't get increased reliability from it. Just type safety allows APIs to be expressed in ways you cannot hold them wrong. Heck, just getting a Result<u32, u32> instead of a i64 for faillible operations is a godsend.
In the end, this is why I'm a big proponent of Rust for many areas of programming, including areas where memory safety is the least of your concerns. My gRPC APIs are written in Rust, my system daemons are written in Rust, my eBPF probes are written in Rust. Rust is a modern language whose design is deliberate on many levels to address common issues in programming. If you'd ask me, Rust's "marketing" putting memory safety first is quite a disservice as there are many areas where it helps writing correct programs.
Greg KH noted this in his email in another branch of the thread, and I wholeheartedly agree with him.
Arguably unsafe Rust is a bit less safe than C. But fortunately you need much less of it (even in something like a DMA subsystem there's going to be plenty of safe code).
https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/
eBPF is such a supertool that is slept on. I have been working on turning my nftables into it, (on low-latency/high-throughput targets) may I ask how you are using it with Rust?
Sure! I use the aya framework (https://aya-rs.dev) that provides the kernel-side bindings to write the probes in Rust, and the userspace tooling to load it in the kernel, interacts with maps, etc. Quite a joy to work with, and has all the niceties you'd expect from using Rust.
We write XDP apps for custom dataplanes where traditionally DPDK would be used (routers and such). Our upcoming network acls are written this way, so close to your netfilter usage.
> Even unsafe rust is safer than C.
Even Zig is safer than unsafe Rust.
I think the "drama" is that the DMA guys want to write C, only.
However they have opinions about how people are interfacing with their code for DMA from Rust, and the rust developers are maybe bent out of shape about it.
Linus is saying: If you're not doing it, then you don't get to have opinions.
> Linus is saying: If you're not doing it, then you don't get to have opinions.
But eventually he would have to, if those rust interfaces becomes part of kernel. The entire drama is about DMA guys not wanting to deal with this in future.
They're trying to do DMA in C, by calling the existing DMA code that's written in C from new drivers written in Rust. Their attempt to make an interface from Rust to the existing DMA code is what's being rejected by the guy maintaining the existing DMA code.
I disagree. The Rust code has an abstraction for DMA’d objects that gives them a safe interface.
It's a shame that it took Hector Martin completely burning out and publicly melting down for Linus to step up and finally Do Something about this situation. This should have been resolved much earlier by Linus, so that less R4L contributors didn't have to publicly quit before we got to this point.
From his blog seems to me that the entitled users where one of the biggest problems, if wasn't them complaining and always demanding more he wouldn't feel pressured to upstream everything immediately