[menaerus]

It has certainly not been made simply because of the fact that Linus is not a boss to the people who are contributing or maintaining the code. There was however a decision to have Rust as an experiment in the kernel but not such that it will bend and change the rules and put a technical burden on everyone else. This issue is solely a technical burden and not a good guy vs bad guy, as many Rust developers would like it to appear by cherry picking the comments from the context.

I think you missed the Linus reply on the topic

> How about you accept the fact that maybe the problem is you.

> You think you know better. But the current process works.

> It has problems, but problems are a fact of life. There is no perfect

[steveklabnik]

Linus is not a boss, that's correct, but he is the BDFL. He doesn't always choose to make every decision himself, but the decision to allow Rust in the tree was made by him.

> not such that it will bend and change the rules and put a technical burden on everyone else.

Absolutely. That is very important. We are in agreement here.

> This issue is solely a technical burden

Here are the entirety of the arguments made:

"No rust code in kernel/dma, please" when no Rust code was being added to kernel/dma.

"Keep the wrappers [duplicated in every driver] instead of making life painful for others." and "interfaces to the DMA API should stay in readable C code". He is not responsible for those wrappers, nor for fixing them when the underling APIs change. This is an argument against the existence of a Rust API for DMA in general, on the conceptual grounds that it exists at all, not a technical argument.

"Maintaining multi-language projects is a pain I have no interest in dealing with. If you want to use something that's not C, be that assembly or rust you write to C interfaces and deal with the impedence mismatch yourself as far as I'm concerned." They have already agreed to this.

"If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver" it was already decided that a cross-language codebase is acceptable in general. That is, it is on technical grounds (though poorly argued), but since a conclusion was come to already, it's no longer a technical argument, it's disagreeing with the process itself.

"The common ground is that I have absolutely no interest in helping to spread a multi-language code base. I absolutely support using Rust in new codebase, but I do not at all in Linux." This is a non-technical argument.

That's it. All of the technical aspects were agreed to. The only other arguments are either about the process in general, or ideological.

> not a good guy vs bad guy,

I do not think He is a bad guy. I think he is being obstructionist on ideological grounds, and does not bring anything new to the table.

> I think you missed the Linus reply on the topic

In this case, Linus is talking to Hector, who is not involved in the patch, nor as far as I know a member of Rust for Linux, though he does support their aims. He purely replied to the social media stuff, and made no comments on the patch or the arguments about it.

[menaerus]

So do you disagree with the fact that merging and testing the code will be much more difficult or you simply choose to ignore it for the sakes of idealogical wars?

[steveklabnik]

I think that statement is too broad to be useful. To make a decision like this, you need to actually argue the real pros and cons of doing so, rather than just saying "it's much more difficult."

All of this was brought up and discussed thoroughly when the experiment was greenlit, and any difficulties created by including Rust, "much more" or no, was deemed an acceptable tradeoff for the benefits of doing so. That's engineering.

[menaerus]

Sure, engineering is all about the tradeoffs, there's no black and white.

So, what is an advantage of mixing two different languages over one kernel module, in this example DMA? What problem does introducing another language solve and what would be the alternatives?

[steveklabnik]

> So, what is an advantage of mixing two different languages over one kernel module,

This is not what is happening. What is happening is the C module is getting a Rust wrapper, to make Rust code be able to call into it more easily. This is because Rust is currently being used for drivers, and DMA is very useful for drivers, so they need to call into the C code somehow.

> What problem does introducing another language solve and what would be the alternatives?

The ones Linus found persuasive are mostly that Rust's memory safety can bring more stability and security to the kernel, and that Rust is likely to attract new developers. Obviously that's just some of it, but those are the main technical and social benefits from including Rust.

The alterative is to not do it.

[menaerus]

> What is happening is the C module is getting a Rust wrapper,

Yes, I understand that. I read the argument on the mailing list. The issue is that changing the DMA code will in turn potentially break the drivers written in Rust and the maintainer has no incentive to do that extra mile himself to make this not to happen. Rust devs OTOH offer say "we're gonna help you fix it" but this obviously creates an extra technical and communication burden. This also means that the future might look like "xy DMA patch didn't manage to get into this release because we didn't manage to fix all the zy Rust dependencies".

To make this work swiftly every kernel developer would need to become very comfortable with at least two toolchains and two very different programming languages. Otherwise, it's simply too complicated and it's a real issue that I do not see as ideological. I think this is a big ask.

> The ones Linus found persuasive are mostly that Rust's memory safety can bring more stability and security to the kernel

This is the tricky part - apart from the theory, we don't actually know that. We don't know if the immediate effects of kernel code written in Rust would result with X times less segmentation-faults or CVEs. This is a hypothesis that is especially tricky to be proven in the kernel-level code, a code that is destined to be using a lot of unsafe blocks.

Even if that hypothesis would have been somehow proven, from an engineering PoV, the pain that it aims to solve still needs to be quantified in order to assess if the change is worth it or not. I don't have that number but I honestly don't think that kernel developers spend too much of their time and resources fixing the memory-related bugs. If they did, then there would be a pretty convincing and strong incentive for them to switch, wouldn't it?

So, when we put the dogmatic arguments aside and put those few (big and important) things into a perspective, I think it is not unrealistic to have people oppose to the idea.