> 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.

> 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.

> 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.

He has no reason to do anything to make it not happen. He is 100% within his rights to ignore things entirely.

> Rust devs OTOH offer say "we're gonna help you fix it" but this obviously creates an extra technical and communication burden.

No, they say "we are going to fix it." He has no responsibility for Rust code. This is the terms of the experiment, which has been clear for years now.

> "xy DMA patch didn't manage to get into this release because we didn't manage to fix all the zy Rust dependencies".

This is not how the process works. All DMA patches get in, if the Rust is broken, it would be "The Rust code that depends on DMA did not get in this release."