Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hector Martin – [Patch] Maintainers: Remove Myself

lkml.org

Post reply on HN
Print view View original

41–50 of 54 posts

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#41

Post by pulsartwin »

uecker wrote: post #34
steveklabnik wrote: post #33

Earlier quoted context omitted.

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 bein…

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.

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#42

Post by uecker »

pulsartwin wrote: post #41
uecker wrote: post #34

Earlier quoted context omitted.

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 sc…

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

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#43

Post by pulsartwin »

uecker wrote: post #42
pulsartwin wrote: post #41

Earlier quoted context omitted.

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 sc…

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

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#44

Post by phendrenad2 »

steveklabnik wrote: post #11
phendrenad2 wrote: post #9

This whole thing is, at it's core, an architectural question. It's quite simple: How much should the C code have to change to allow better Rust support? Despite his position as "Benevolent dictator for life", Linus doesn't really have the chutzpah to stand up and say "we're doing it this way"[1], so these sorts of questions try to get resolved through petty bickering and namecalling instead (which is the opposite of…

That question as already answered when the experiment was greenlit: it doesn’t have to at all. That question is also not what is at the heart of this conflict. It’s someone that categorically rejects the experiment, even though the project has decided to give it a try. It’s entirely social and not technical.

> That question as already answered when the experiment was greenlit: it doesn’t have to at all

Where? And in light of the ongoing infighting and lack of clear parameters, do you think that was truly sufficient?

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#45

Post by steveklabnik »

phendrenad2 wrote: post #44
steveklabnik wrote: post #11

Earlier quoted context omitted.

That question as already answered when the experiment was greenlit: it doesn’t have to at all. That question is also not what is at the heart of this conflict. It’s someone that categorically rejects the experiment, even though the project has decided to give it a try. It’s entirely social and not technical.

> That question as already answered when the experiment was greenlit: it doesn’t have to at all Where? And in light of the ongoing infighting and lack of clear parameters, do you think that was truly sufficient?

When the Rust for Linux experiment was approved.

It was sufficient, but that doesn’t prevent people from acting in bad faith. Which is what is happening here.

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#46

Post by menaerus »

steveklabnik wrote: post #37
menaerus wrote: post #36

Earlier quoted context omitted.

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?

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

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

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#47

Post by uecker »

pulsartwin wrote: post #43
uecker wrote: post #42

Earlier quoted context omitted.

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.

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#48

Post by steveklabnik »

menaerus wrote: post #46
steveklabnik wrote: post #37

Earlier quoted context omitted.

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

> 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 technica…

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

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#49

Post by phendrenad2 »

steveklabnik wrote: post #45
phendrenad2 wrote: post #44

Earlier quoted context omitted.

> That question as already answered when the experiment was greenlit: it doesn’t have to at all Where? And in light of the ongoing infighting and lack of clear parameters, do you think that was truly sufficient?

When the Rust for Linux experiment was approved. It was sufficient, but that doesn’t prevent people from acting in bad faith. Which is what is happening here.

It may be technically insufficient, if the RfL folks can't integrate Rust without C changes. And if that's true, (and it seems to be true) then it's time for an architectural discussion to come to an agreement on if Rust for Linux should be pursued or if C code flexibility and readability is more important.

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#50

Post by whytevuhuni »

phendrenad2 wrote: post #49
steveklabnik wrote: post #45

Earlier quoted context omitted.

When the Rust for Linux experiment was approved. It was sufficient, but that doesn’t prevent people from acting in bad faith. Which is what is happening here.

It may be technically insufficient, if the RfL folks can't integrate Rust without C changes. And if that's true, (and it seems to be true) then it's time for an architectural discussion to come to an agreement on if Rust for Linux should be pursued or if C code flexibility and readability is more important.

> if the RfL folks can't integrate Rust without C changes

The RfL folks can integrate Rust without C changes.

All of the changes in the patch (ever since v1) have been entirely contained inside the rust directory, with most of the changes being in the rust/kernel/dma.rs file. There were no changes to C files, or to files inside the kernel/dma directory.

Post reply on HN