Where? Because "keep the wrappers in your code" and "do that in your driver so that you have to do it instead of spreading this" doesn't sound like that.
>Every additional bit that another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language completely breaks this. You might not like my answer, but I will do everything I can do to stop this.
I think that clearly means he is out to sabotage any other language than C making it into Linux.
This was also on a patch that did "keep the wrappers in [rust-folder, not DMA] code". Arp242's interpretation isn't just belied by the direct words of the maintainer, it's belied by the fact that the code the maintainer rejected was exactly what Arp242 is suggesting the maintainer was asking for.
I wouldn't call being vocally against something "sabotage". Would it be reasonable if that person said anyone trying to get rust integrated is sabotaging the Linux kernel?
You're conflating two things. The fact that he voices his belief that Rust is harmful for kernel development is fair.
The fact that he is using his powers as maintainer of the DMA module to prevent Rust code from being added, with the explicit goal of making it harder to develop Rust drivers so that maybe the Rust-for-Linux project might get abandoned is an explicit act of sabotage against the R4L project (no one is saying he is sabotaging the Linux project itself).
In contrast, even accepting the "two languages bad" perspective, you can't call the R4L project "sabotage" in the same way, because they are clearly not intending to prevent or break anything in the Linux kernel, even if you think they will end up doing so as this maintainer does.
>The fact that he is using his powers as maintainer of the DMA module to prevent Rust code from being added
This is a misinterpretation of the facts. It's not actually up to Hellwig whether or not the patch gets accepted; the relevant maintainer that would merge the patch is somebody else.
He's totally within his right to express his opinion in a NACK.
At least at some point, the proposal was to add this code in the DMA submodule, where he did have the ~final say whether it would be merged in.
When it became clear that wasn't an option, they decided to put it somewhere else, but since he'd been consulted, he still wanted to make it clear he isn't ok with the patch regardless of where the files go or any other aspect of it; but you're right that he is not the final authority on what code goes into that new subpath.
I never said in any way that he doesn't have a right to his opinion. Just that he is explicitly and vehemently opposed to Rust in the kernel, and to anything that makes that easier to happen.
You're comparing the actual intent of one side of the argument to a watered down version of the other side. "I will do anything in my power to stop this" is the stated intent of sabotage, not "I'm vocally stating my opposition to this" If someone said "I will do anything in my power to stop Linux development to proceed without Rust integrated into it", then yes, that would sound like intent to sabotage, but that's not anywhere close to what anyone is saying.
So there's actually a reasoning behind this and not just personal preference or someone being stubborn. And as someone who has maintained large old code bases I must say the reasoning sounds pretty convincing.
If any of
> Every additional bit that another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language completely breaks this.
is correct, he is actually fighting against sabotage.
This [0] seems to be the closest to your parent's statement:
> 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.
He needs really to be removed from the process. He may be useful for now but for long term he is an impediment. C is the 1970’s. Sure it’s proven itself… but so had Assembly when Unix was invented.
