The Linux kernel mailing list drama around the Rust programming language use within the kernel continues… Linus Torvalds has largely refrained from the ongoing LKML discussions around a Rust policy for the Linux kernel and in-fighting between kernel developers and maintainers with differing views over Rust. This evening though Linus Torvalds did decide to chime in on the conversation.
While there was the commentary a few days ago that Linus Torvalds reportedly said he would merge Rust kernel code over maintainer objections, in responding to Christoph Hellwig he further clarified his position. Hellwig with his DMA maintainer hat on has been against the Rust code with DMA areas of the kernel. Linus Torvalds responded tonight clarifying that maintainers can either choose to take an active role with Rust bindings for areas of the kernel they oversee and become involved or have a hands-off approach where it’s more complementary to their code. But kernel maintainers can’t object to new Rust code as effective “users” of their C code. Linux kernel maintainers can either engage with any proposed Rust code or choose not to and let it live complementary within the kernel, but that they can’t arbitrarily block it as being a user of their code.
“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).
The fact is, the pull request you objected to DID NOT TOUCH THE DMA LAYER AT ALL.
It was literally just another user of it, in a completely separate subdirectory, that didn’t change the code you maintain in _any_ way, shape, or form.
I find it distressing that you are complaining about new users of your code, and then you keep bringing up these kinds of complete garbage arguments.
Honestly, what you have been doing is basically saying “as a DMA maintainer I control what the DMA code is used for”.
And that is not how *any* of this works.
What’s next? Saying that particular drivers can’t do DMA, because you don’t like that device, and as a DMA maintainer you control who can use the DMA code?
That’s _literally_ exactly what you are trying to do with the Rust code.
You are saying that you disagree with Rust - which is fine, nobody has ever required you to write or read Rust code.
But then you take that stance to mean that the Rust code cannot even use or interface to code you maintain.
So let me be very clear: if you as a maintainer feel that you control who or what can use your code, YOU ARE WRONG.
I respect you technically, and I like working with you.
And no, I am not looking for yes-men, and I like it when you call me out on my bullshit. I say some stupid things at times, there needs to be people who just stand up to me and tell me I’m full of shit.
But now I’m calling you out on *YOURS*.
So this email is not about some “Rust policy”. This email is about a much bigger issue: as a maintainer you are in charge of your code, sure - but you are not in charge of who uses the end result and how.
You don’t have to like Rust. You don’t have to care about it. That’s been made clear pretty much from the very beginning, that nobody is forced to suddenly have to learn a new language, and that people who want to work purely on the C side can very much continue to do so.
So to get back to the very core of your statement:
“The document claims no subsystem is forced to take Rust”
that is very much true.
You are not forced to take any Rust code, or care about any Rust code in the DMA code. You can ignore it.
But “ignore the Rust side” automatically also means that you don’t have any *say* on the Rust side.
You can’t have it both ways. You can’t say “I want to have nothing to do with Rust”, and then in the very next sentence say “And that means that the Rust code that I will ignore cannot use the C interfaces I maintain”.
Maintainers who *want* to be involved in the Rust side can be involved in it, and by being involved with it, they will have some say in what the Rust bindings look like. They basically become the maintainers of the Rust interfaces too.
But maintainers who are taking the “I don’t want to deal with Rust” option also then basically will obviously not have to bother with the Rust bindings - but as a result they also won’t have any say on what goes on on the Rust side.
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.
But that “wall of protection” basically goes both ways. If you don’t want to deal with the Rust code, you get no *say* on the Rust code.
Put another way: the “nobody is forced to deal with Rust” does not imply “everybody is allowed to veto any Rust code”.
See?
And no, I don’t actually think it needs to be all that black-and-white. I’ve stated the above in very black-and-white terms (“becoming a maintainer of the Rust bindings too” vs “don’t want to deal with Rust at all”), but in many cases I suspect it will be a much less harsh of a line, where a subsystem maintainer may be *aware* of the Rust bindings, and willing to work with the Rust side, but perhaps not hugely actively involved.
So it really doesn’t have to be an “all or nothing” situation.
Linus”
That’s where things currently stand in this Rust debate for Linux kernel code.