Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't entirely disagree with some of your points, however, they are not what the recent discussion has been about. Plainly, a maintainer has unilaterally rejected the addition of rust code to assist with DMA and requested that code be duplicated in every driver (which also ignores the fact that the patch never added rust code to kernel/dma to begin with). It strikes many as strange that the experimental addition of rust-based drivers (greenlit by Linus orignally) has come to a head in this way:

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



I think rejecting code in his area is his right as a maintainer of this area (to the extend this is the case, I haven't checked). Also the patch adds a file kernel/dma.rs so I am confused about your comment. I also happen to agree that maintaining multi-language code is a pain and I understand that he does not want this imposed on him. This may make it harder for Rust kernel developers, but I can not see how this is "sabotage of the project".


> (to the extend this is the case, I haven't checked)

It's not his area.

> Also the patch adds a file kernel/dma.rs so I am confused about your comment.

It adds rust/kernel/dma.rs, not kernel/dma. That is, it adds that file here: https://github.com/torvalds/linux/tree/master/rust/kernel not here: https://github.com/torvalds/linux/tree/master/kernel/dma


If it is not his area, he should have no power to stop it anyway, so it is even more strange to call it "sabotage". Or has any kernel developer the right to nack anything? This seems unlikely to me. So then it is just some disagreement.


You have to remember that Linux development isn't done like most open source projects where there's one upstream tree everyone sends patches to. Linus pulls in whatever code he wants. A nack means that Hellwig won't pull it into his tree, but that doesn't mean it can't go in someone else's, and end up upstream anyway. The only reason he was even cc'd on the patch is because he's the relevant subsystem maintainer being wrapped, as a courtesy.


As I said, the idea that this is then "sabotage" is completely ridiculous and just shows how toxic this maintainer was that now removed himself.


There are multiple comments that meet the exact definition of sabotage. If this:

"You might not like my answer, but I will do everything I can do to stop this."

is not intent to sabotage (even if it might not be successful as Linus could pull in the patch anyway), then what possibly could be?

Pointing out the ridiculousness of comments like this and suggesting the R4L folks push forward while ignoring them doesn't scream toxicity. Refusing to compromise with the R4L devs and calling the additions a 'cancer' has expectedly caused a stir.


I think you need to look up "sabotage" in the dictionary.


sabotage /ˈsabətɑː(d)ʒ/ verb

1. deliberately destroy, damage, or *obstruct* (something), especially for political or military advantage.

2. to intentionally prevent the success of a plan or action.

Definitions from Oxford, Collins, and Cambridge all fit the bill. Even dictionary.com has "any undermining of a cause."


Yes, and now compare to what happened. You could differentiate between words and actions and what exactly was affected. For someone to "sabotage the Rust experiment in the kernel" you would need to determinate that that person did something that a) effectively damaged / obstructed the project (which - if GP is right about that that person has no power to stop the merging of the patch anyway - is a dubious claim), etc.

Misrepresenting the voicing of opposition to some process as "sabotage" seems completely out of line for a any kind of community project. If you define things so loosely, then every side in any disagreement could always label the other side of doing "sabotage". This reflects the sentiment of many Rust people to "be on the right side of history" where everybody else automatically is wrong and even voicing objects and criticism is already "sabotaging" on the true path.


If you don't think what Hellwig did obstructed the project, then I guess we fundamentally disagree. Again, the R4L folks could work around this by getting the code pulled in by Linus, but that doesn't stop the fact that a senior maintainer has made it explicit that they will do everything in their power to stop this.

Code that wasn't his to reject was NACKed, causing a large amount of uncertainty about how to proceed with drivers that use DMA, and around the R4L project in general. At the absolute least, this is plain intent to sabotage (but IMO it is clearly more than intent at this stage). The core of what you are saying is that this has/will have absolutely no impact on anything to do with future R4L progress. The explosion of discussions around this exact topic across various forums with abundant disagreement from maintainers and R4L folks running counter to that idea are irrelevant I guess.

I'm not even a "rust person" and nobody has said anything about "being on the right side of history" except you. If that's how you see this discussion then we're not going to get anywhere. I wish you well, and urge you to in future engage in good faith and consider that not everybody is some boogeyman "on the true path" evangelist.


A senior maintainer has a different opinion and expresses it. Your point seems to be that because he is not on board with the plan and expresses this, this is already "sabotage". Of course it makes things harder if not everybody agrees. But this is not the same thing that people disagreeing with your plan and say so do "sabotage". Sorry, this is ridiculous.


There is a large difference between "I do not think this is a good idea" vs "do not do this", in particular given the position Hellwig has in the kernel as a listed maintainer of the DMA mapping helpers.

No single technical reason was given besides a non-specific opinion on the "messiness" of multi-language projects.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: