In my opinion, calling the well-intentioned hard work of others "cancer" is undeniably hyperbolic and dismissive. It is clear that Hellwig used it in this way. To interpret it differently requires bending the mind. Most people would also consider it rude, but I'll grant that rudeness is more subjective.
There is an argument that being hyperbolic, dismissive, and maybe a bit rude isn't as bad as some people make it out to be, and that it is a fine way to hash out disagreements and arrive at the best solution - that it is simply a result of the passion of exceptional engineers. There has historically been much of it in kernel development. But it seems that as the background and culture of kernel maintainers has broadened, that a more measured and positive approach to communication is more constructive.
It doesn't seem like marcan exemplifies this very well either. It is a loss for someone so skilled to abandon collaboration on the kernel, and seems like the unfortunate result of someone being dismissive and rude, and someone else taking that harder than is warranted or healthy.
"To interpret it differently requires bending the mind."
Stange, I think interpreting it your way requires bending the mind. Hellwig clearly used it to describe what he sees at the ill effects of multiple languages in the kernel. It was not used to describe either Rust the language or this specifically this particular submission.
> And I also do not want another maintainer. If you want to make Linux
impossible to maintain due to a cross-language codebase do that in
your driver so that you have to do it instead of spreading this cancer
to core subsystems. (where this cancer explicitly is a cross-language
codebase and not rust itself, just to escape the flameware brigade).
It was used to describe the Rust for Linux project, as well as any other potential efforts to bring other languages into the kernel, of which there are none. It is clear why someone working on the Rust for Linux project would feel that "this cancer" refers to the project that they are working on.
I'm not trying to pull out pitchforks, I don't want anyone to burn. I just want people to collaborate effectively and be happy, and I think it is empirically clear that calling something that grows/spreads and that you think is bad "cancer" is not useful, and only inflames things. It is not an illuminating metaphor.
I agree with Vegenoid that using diseases for labeling poorly written code is at the very least highly unprofessional. This practice not only diminishes the seriousness of illnesses like cancer when used so casually, but it also cannot provide helpful constructive feedback.
Instead of providing helpful advice like outlining the current situation and suggesting specific improvements (action A, task B, and goal C) to reach the goal, it feels rude and offensive.
There is no specific improvement if the problem is fundamental. There is no "better/right" way to spread a cancer. (I'm not saying it is, just that that is the argument, and in that context, there is no such thing as a common goal to reach some better way. Everyone does not actually have to agree that all goals are valid and should be reached.)
The only helpful advice, which they did give, is don't even start doing this because it's fundamentally wrong.
The linux kernel is like a house where everyone is a vegan. Marcan believes that incorporating some meat in the diet is important, and better that being a vegan. He may even be right. But so what? He makes his pitch, the family says that's nice but no thanks. He then demands that they eat this chicken because he wants to live in the house and wants to eat chicken while living in the vegan house?
I don't see how he has any right to what he wants, and I don't see an existing kernel devs refusal to cooperate, or even entertain cooperating, as automatically wrong or unreasonable.
> The linux kernel is like a house where everyone is a vegan. Marcan believes that incorporating some meat in the diet is important, and better that being a vegan. He may even be right. But so what? He makes his pitch, the family says that's nice but no thanks. He then demands that they eat this chicken because he wants to live in the house and wants to eat chicken while living in the vegan house?
While I think this a dumb metaphor, it's also incorrect in this context. The Linux kernel explicitly supports C and Rust code, and there are very clear parameters to allow for Rust code to be integrated into parts of the kernel.
Or in other words, the decision has already been made to allow meat into the vegan household, and now one maintainer is explicitly blocking a package of meat from entering the building, even though it has already been decided from on high that meat should be allowed in.
This isn't quite accurate, though, because of the unnecessary metaphor thing. Reading the original mailing list chain all the way through and talking about these events directly is completely sufficient here. The patch was reasonable within the parameters set out for the R4L project. The maintainer of this subsystem blocked it explicitly because they disagree with the idea of R4L in general (calling it a cancer).
The question is not whether or not R4L is a good thing or a bad thing - anyone can have their own opinion on that. R4L is part of Linux, and will be for the foreseeable future, until it either clearly demonstrates its use, or clearly demonstrates its failure. The question (at least as regards the "cancer" comment) is whether it is okay for a maintainer to describe another team's work as cancer, and to publicly block it as much as they can.
Of course it's ok to block something they judge to be harmful as much as they can. That is their explicit job as maintainer is to make exactly that type of judgement.
If they are overstepping, then Linus will make that known. Until then, apparently they are not overstepping.
And he can use that image if it communicates the concept he wants to communicate.
It sounds like a valid image to me to apply to the concept of polyglot.
He is saying that "If there is really no way for a rust driver to exist all by itself without any of the c code having to do anything special to accomodate it, then so be it, I guess rust doesn't fit here after all."
rust devs are saying "you're not even helping a tiny bit!". I am saying, no, they're not, so what? They don't have to. They did not request what rust devs are trying to do.
The concession rust devs got to proceed to attempt to use rust in the kernel at all doesn't promise almost anything beyond "well you can try". It does not promise to facilitate that try at all really.
Even if you put that aside, the problem is you offer Hellwig two solutions and he NACKs them both.
H: I don't want to support multilanguage codebase
R: We'll have a maintainer verify R4L is behaving properly.
H: I solved issues because they were unified.
R: Rust will be mirror of whatever C is, and you're free to break it, R4L will maintain it.
H: No.
I'll bite and play devils advocate here - both of those are not a solution to his problem. Ultimately he's the maintainer and he gets the emails if X driver is broken, so because of that he doesn't want to rely on another group to maintain the 'Rust half' of his part of the code. It's also a system that works until it doesn't, the biggest rule of the kernel is no breaking userspace - at some point in the future it won't matter if it's his C changes breaking the Rust drivers, it's still his changes that have to be rolled back if the Rust code isn't updated.
And to clarify I'm not saying he's right or wrong or acting good or bad. I have however expected R4L to ultimately fall apart because of this exact issue, the maintainers have never been on board with maintaining Rust code and that hasn't changed. While that remains the case the project is going to be stuck at a wall - to the point that if they're confident they can maintain the Rust code themselves they should just fork it and do that. If it works well enough they'll eventually be too popular to ignore with people choosing to write their new modules in Rust instead.
That is not a problem. Christoph does not have the right to gatekeep who can use DMA. If he tried to veto an Nvidia graphics driver from using DMA using the excuse that "it might create more work for me", everyone would rightfully tell him to f-off, because that's not his call.
He meant to say "the Rust code will spread everywhere [like cancer]".
I agree it's rude, offensive, and hostile, but there are degrees of things and context matters. "You are cancer" would be much worse. I feel we should try and interpret things in good faith and maintain some perspective. For a single word like this: you can just read over it (which is also what the other Rust people did).
Certainly outright removing Hellwig from the Linux project, as Marcan suggested, is bizarrely draconian.
He wasnt talking about Rust specifically, he was referring to codebases in any other language.
He said:
“ And I also do not want another maintainer. If you want to make Linux
impossible to maintain due to a cross-language codebase do that in
your driver so that you have to do it instead of spreading this cancer
to core subsystems. (where this cancer explicitly is a cross-language
codebase and not rust itself, just to escape the flameware brigade).”
> It was perfectly clear what Hellwig meant by "cancer".
No, it is not perfectly clear.
The generous interpretation is that they meant it is "viral", spreading through dependencies across the codebase (which I don't think is technically accurate as long as CONFIG_RUST=n exists).
The less generous way to interpret it is "harmful". The later messages in the thread suggests that this is more likely.
But I'm left guessing here, and I'm willing to give some some benefit of doubt here.
That said, the response to this comment was incredibly bad as well.
And he's not just abrasive He's a troublemaker. Seriously, code of conduct violation? It was perfectly clear what Hellwig meant by "cancer".