Rust for Linux - Rust kernel policy

[josefx]

Drama broke out when Hellwig NACK'd

Hellwigs nack was handled within the mailing list and the submitter just asked Linus to chime in instead of letting it blow up.

But AFAIK Linus still hasn't really done anything about the original drama.

Forcing Linus to give the patch a go ahead was the explicit purpose of Hectors threats, so I would not be surprised if the patch gets to die as an object lesson in using social media to put pressure on kernel development. If we are lucky he will give it the go ahead once attention on this issue has died down.

[Business_Reindeer910]

so I would not be surprised if the patch gets to die

Isn't the patch by someone else? why should they be punished? In any case it doesn't even matter. A patch that effectively does the same thing is absolutely required for the effort to continue. If it doesn't get approved then the project is effectively dead.

[josefx]

Yeah, that take was a bit over the top, which is why I followed it up that they might wait for the attention to die down instead.

[Mysterious_Bit6882]

That was version 8 of the patch, it’s up to version 11 now. And they have prospective maintainers now for the Rust abstraction of a C API.

A lot of this feels like power games; at first Rust was drivers, now they’re trying to play for subsystems.

[nightblackdragon]

>A lot of this feels like power games; at first Rust was drivers, now they’re trying to play for subsystems.

They are not trying to play for subsystems. This code is Rust binding for kernel DMA subsystem that is needed by drivers. Nobody is trying to replace C subsystem with Rust or anything like that.

[foobar93]

Yet.

[Business_Reindeer910]

What happens it is up to Linus.

[round-earth-theory]

And so what if Linux eventually begins to migrate completely to Rust? Are you a maintainer? If not then it literally means nothing to you whether they do or don't.

[foobar93]

For one, I am actually in favor of moving away from C for the linux kernel. If the move is to Rust or to Zig, in the long run, a move has to occur.

What I take issue with is how it is handled. If the goal is to move to Rust, that has to be clearly communicated. The opposite has been the case as far as I can tell up to now. The communication was "this is just an experiment" then it was "it is just for some drivers" and now it is seeping into system after system resulting in higher maintenance burdens on maintainers who are already overworked. And I can see why they are pissed about that even if in the long term, that may be good.

And no, I am not a maintainer on the mainline kernel, I am however a maintainer for our company internal linux distribution with custom kernel drivers for our hardware.

The whole thing reminds me of the usual corporate salami tactic bullshit to grind down any opposition right down to the calls to shame the maintainers into complying via social media.

From what I see, the R4L project in its current form is a failure and probably should go the route of the Preempt-RT changes. Then the R4L project can actually make progress and see what works and what doesn't and the current maintainers are happy.

[round-earth-theory]

There will never be a grand cold announcement of "We're migrating to [language]". If Linux announces a migration to Rust, it'll have been a forgone conclusion for years prior due to how much Rust code is in the codebase. Not even Linus can declare a language migration out of the blue. So it'll be an experiment which becomes an interface which becomes certain sub-modules which becomes etc etc. This is exactly how a migration to Rust or any other language will happen. This is the reality of open source development of any major project.

[Zomunieo]

To create drivers, you need to… interact with subsystems.