6 ms·

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? Despit

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 consensus-building and healthy debate and just makes people more entrenched and unwilling to compromise). [1] - He was already ousted from the project once, I don't think he wants to try it again.

steveklabnik 2y ago
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.
- uecker 2y ago
  I don't think this is a fair characterization. I think the accusations from the Rust side that the project is "sabotaged" or "non-technical arguments" etc. are a typical symptom of denial. All the hype and enthusiasm related to Rust is that you can just write something easily in C instead of Rust (or rewrite) and then all problems related to safety are solved. And some of those people really believe this nonsense. The real world complexities unsurprisingly do not go away simply by using Rust. The signs are all over: The project is moving very slowly, the very enthusiastic people who move it along with sheer will power get burned out, there also CVEs in Rust code, etc. But if you bought all the Rust arguments and are now invested, it is difficult to accept that the solution of the safety problems is not as simple "rewrite to Rust". So the more immature part of the Rust communities starts to blame politics. Now, I do not want to say that there are not grains of truth in all these points (I do think memory safety is great, I do think that C ecosystem has issues, I agree that there are many good ideas in Rust, and certainly skepticism from others makes it harder to push something forward in a community, etc.), but overall I think it is mostly delusional ideas from Rust folks encountering the real world, and instead of critical self-reflection on what needs to improved both in terms of social aspects of collaboration and maybe also on the technical side, they blame others for sabotaging the project and organize a social media circus to force their ideas on a community (which of course, is super toxic and evil)
  - pulsartwin 2y ago
    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."
    - uecker 2y ago
      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".
      - steveklabnik 2y ago
        > (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 https://github.com/torvalds/linux/tree/master/rust/kernel not here: https://github.com/torvalds/linux/tree/master/kernel/dma https://github.com/torvalds/linux/tree/master/kernel/dma
        uecker 2y ago
        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.
- menaerus 2y ago
  The reason is entirely technical and I think it has been formulated clearly - maintaining cross-language codebase, or one of the most important kernel modules FWIW in this case, certainly does not make things simpler but only more complex - communication-wise, time-wise, resource-wise, uncertainty-wise etc. I think this is pretty clear and not really debatable IMO. The actual question is if that overhead is worth it and it seems that there is no clear answer on that question despite many Rust-force claiming otherwise. I can totally understand the position of kernel maintainers. What I cannot understand is the following shameful, almost unbelievable, act from Hector Martin > If shaming on social media does not work, then tell me what does, because I'm out of ideas. If there's a single most reason why Rust-in-Linux will fail it is going to be because of the immaturity and entitlement of individuals in Rust community.
  - steveklabnik 2y ago
    That technical decision has already been made, by Linus: it is acceptable for the purposes of this experiment, and possibly, for good. So objecting on those grounds is a project management issue.
    - menaerus 2y ago
      It has certainly not been made simply because of the fact that Linus is not a boss to the people who are contributing or maintaining the code. There was however a decision to have Rust as an experiment in the kernel but not such that it will bend and change the rules and put a technical burden on everyone else. This issue is solely a technical burden and not a good guy vs bad guy, as many Rust developers would like it to appear by cherry picking the comments from the context. I think you missed the Linus reply on the topic > How about you accept the fact that maybe the problem is you. > You think you know better. But the current process works. > It has problems, but problems are a fact of life. There is no perfect
      - steveklabnik 2y ago
        Linus is not a boss, that's correct, but he is the BDFL. He doesn't always choose to make every decision himself, but the decision to allow Rust in the tree was made by him. > not such that it will bend and change the rules and put a technical burden on everyone else. Absolutely. That is very important. We are in agreement here. > This issue is solely a technical burden Here are the entirety of the arguments made: "No rust code in kernel/dma, please" when no Rust code was being added to kernel/dma. "Keep the wrappers [duplicated in every driver] instead of making life painful for others." and "interfaces to the DMA API should stay in readable C code". He is not responsible for those wrappers, nor for fixing them when the underling APIs change. This is an argument against the existence of a Rust API for DMA in general, on the conceptual grounds that it exists at all, not a technical argument. "Maintaining multi-language projects is a pain I have no interest in dealing with. If you want to use something that's not C, be that assembly or rust you write to C interfaces and deal with the impedence mismatch yourself as far as I'm concerned." They have already agreed to this. "If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver" it was already decided that a cross-language codebase is acceptable in general. That is, it is on technical grounds (though poorly argued), but since a conclusion was come to already, it's no longer a technical argument, it's disagreeing with the process itself. "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." This is a non-technical argument. That's it. All of the technical aspects were agreed to. The only other arguments are either about the process in general, or ideological. > not a good guy vs bad guy, I do not think He is a bad guy. I think he is being obstructionist on ideological grounds, and does not bring anything new to the table. > I think you missed the Linus reply on the topic In this case, Linus is talking to Hector, who is not involved in the patch, nor as far as I know a member of Rust for Linux, though he does support their aims. He purely replied to the social media stuff, and made no comments on the patch or the arguments about it.
- phendrenad2 2y ago
  > 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?
  - steveklabnik 2y ago
    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.
    - phendrenad2 2y ago
      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.
      - whytevuhuni 2y ago
        > 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.

steveklabnik 2y ago

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.

uecker 2y ago
I don't think this is a fair characterization. I think the accusations from the Rust side that the project is "sabotaged" or "non-technical arguments" etc. are a typical symptom of denial. All the hype and enthusiasm related to Rust is that you can just write something easily in C instead of Rust (or rewrite) and then all problems related to safety are solved. And some of those people really believe this nonsense. The real world complexities unsurprisingly do not go away simply by using Rust. The signs are all over: The project is moving very slowly, the very enthusiastic people who move it along with sheer will power get burned out, there also CVEs in Rust code, etc. But if you bought all the Rust arguments and are now invested, it is difficult to accept that the solution of the safety problems is not as simple "rewrite to Rust". So the more immature part of the Rust communities starts to blame politics. Now, I do not want to say that there are not grains of truth in all these points (I do think memory safety is great, I do think that C ecosystem has issues, I agree that there are many good ideas in Rust, and certainly skepticism from others makes it harder to push something forward in a community, etc.), but overall I think it is mostly delusional ideas from Rust folks encountering the real world, and instead of critical self-reflection on what needs to improved both in terms of social aspects of collaboration and maybe also on the technical side, they blame others for sabotaging the project and organize a social media circus to force their ideas on a community (which of course, is super toxic and evil)
- pulsartwin 2y ago
  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."
  - uecker 2y ago
    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".
    - steveklabnik 2y ago
      > (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 https://github.com/torvalds/linux/tree/master/rust/kernel not here: https://github.com/torvalds/linux/tree/master/kernel/dma https://github.com/torvalds/linux/tree/master/kernel/dma
      - uecker 2y ago
        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.
menaerus 2y ago
The reason is entirely technical and I think it has been formulated clearly - maintaining cross-language codebase, or one of the most important kernel modules FWIW in this case, certainly does not make things simpler but only more complex - communication-wise, time-wise, resource-wise, uncertainty-wise etc. I think this is pretty clear and not really debatable IMO. The actual question is if that overhead is worth it and it seems that there is no clear answer on that question despite many Rust-force claiming otherwise. I can totally understand the position of kernel maintainers. What I cannot understand is the following shameful, almost unbelievable, act from Hector Martin > If shaming on social media does not work, then tell me what does, because I'm out of ideas. If there's a single most reason why Rust-in-Linux will fail it is going to be because of the immaturity and entitlement of individuals in Rust community.
- steveklabnik 2y ago
  That technical decision has already been made, by Linus: it is acceptable for the purposes of this experiment, and possibly, for good. So objecting on those grounds is a project management issue.
  - menaerus 2y ago
    It has certainly not been made simply because of the fact that Linus is not a boss to the people who are contributing or maintaining the code. There was however a decision to have Rust as an experiment in the kernel but not such that it will bend and change the rules and put a technical burden on everyone else. This issue is solely a technical burden and not a good guy vs bad guy, as many Rust developers would like it to appear by cherry picking the comments from the context. I think you missed the Linus reply on the topic > How about you accept the fact that maybe the problem is you. > You think you know better. But the current process works. > It has problems, but problems are a fact of life. There is no perfect
    - steveklabnik 2y ago
      Linus is not a boss, that's correct, but he is the BDFL. He doesn't always choose to make every decision himself, but the decision to allow Rust in the tree was made by him. > not such that it will bend and change the rules and put a technical burden on everyone else. Absolutely. That is very important. We are in agreement here. > This issue is solely a technical burden Here are the entirety of the arguments made: "No rust code in kernel/dma, please" when no Rust code was being added to kernel/dma. "Keep the wrappers [duplicated in every driver] instead of making life painful for others." and "interfaces to the DMA API should stay in readable C code". He is not responsible for those wrappers, nor for fixing them when the underling APIs change. This is an argument against the existence of a Rust API for DMA in general, on the conceptual grounds that it exists at all, not a technical argument. "Maintaining multi-language projects is a pain I have no interest in dealing with. If you want to use something that's not C, be that assembly or rust you write to C interfaces and deal with the impedence mismatch yourself as far as I'm concerned." They have already agreed to this. "If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver" it was already decided that a cross-language codebase is acceptable in general. That is, it is on technical grounds (though poorly argued), but since a conclusion was come to already, it's no longer a technical argument, it's disagreeing with the process itself. "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." This is a non-technical argument. That's it. All of the technical aspects were agreed to. The only other arguments are either about the process in general, or ideological. > not a good guy vs bad guy, I do not think He is a bad guy. I think he is being obstructionist on ideological grounds, and does not bring anything new to the table. > I think you missed the Linus reply on the topic In this case, Linus is talking to Hector, who is not involved in the patch, nor as far as I know a member of Rust for Linux, though he does support their aims. He purely replied to the social media stuff, and made no comments on the patch or the arguments about it.
phendrenad2 2y ago
> 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?
- steveklabnik 2y ago
  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.
  - phendrenad2 2y ago
    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.
    - whytevuhuni 2y ago
      > 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.