3 ms·

There's ongoing debate in the Linux community about the use of Rust in the Linux kernel (e.g. wrapping existing APIs safely for driver development). This heated

by janice1999 2y ago

There's ongoing debate in the Linux community about the use of Rust in the Linux kernel (e.g. wrapping existing APIs safely for driver development). This heated up recently. Use of Rust puts requirements on the kernel developers to specify a Rust compiler version to use and ensure C code changes do not break Rust code and vice versa. This has triggered discussions in other communities. The linked discussion is amongst FreeBSD developers about how to conceptualize FreeBSD itself (where compilers, kernel, userspace and ported application code lives) and where compilers like Rust fit into that vision in the future. Unlike Linux, which is just a kernel, FreeBSD is a kernel + userspace + compiler (equivalent to the GNU part of GNU/Linux + GCC or LLVM).

steveklabnik 2y ago
> ensure C code changes do not break Rust code This is not true. C code is allowed to break Rust bindings. The Rust For Linux folks will then go fix it. The C side was repeatedly told this, but doesn’t seem to want to hear it.
- janice1999 2y ago
  As far as I understand it, that is only in the short term for the file system experiment where Rust is a "second class citizen" as Ted T'so put it.
  - steveklabnik 2y ago
    Nobody has decided what the post-experiment policy will be. A second language is new grounds for the kernel. Ted is assuming in order to interfere with the experiment.
- anon-3988 2y ago
  > The Rust For Linux folks will then go fix it. Doesn't this mean that the change will have to be blocked until the Rust side is also fixed? Rust folks are eager to do it now, and there's a lot of "hype" around having Rust but is it going to be the same in, say, 15 years? Userspace Rust is awesome ( aside from being a bit big), but I don't know if Rust in the kernel is proven yet (Time will literally tell).
  - steveklabnik 2y ago
    No. It specifically is being treated as a second class citizen that is allowed to break. Rust is already in the Windows kernel. It’s being used in embedded devices and kernels in production. It has proven itself.
  - estebank 2y ago
    > but is it going to be the same in, say, 15 years? You would think that by then either the Rust experiment has failed or the project has gained enough experienced developers such that maintaining such large refactors is feasible beyond heroics of the RfL folks. Either way it would be unlikely to be a problem then. But in the meantime, how is the Linux project meant to evaluate what the maintenance burden is or wether the benefits outright the costs if the kernel maintainers doing the RfL work are being repeatedly stonewalled?
- JohnFen 2y ago
  A lot of that might have something to do with the fact that the Rust community is incredibly hostile to the C community.
  - steveklabnik 2y ago
    Can you show me where this is happening in the Linux project? I’ve only ever seen hostility from the C folks to the Rust folks. I agree that in general the overall level of hostility in the kernel seems higher than ideal.
    - RandomThoughts3 2y ago
      With all due respect, you might not be completely neutral and unbiased here.
      - steveklabnik 2y ago
        Then show me the evidence. You also say “Rust zealots” above so you yourself (like frankly everyone) have bias as well.
        RandomThoughts3 2y ago
        You are the one implying the C developers are aggressing the Rust crowd, mr formerly professionally employed by the Rust project for outreach person.
        steveklabnik 2y ago
        Everyone is free to watch the video and make up their own minds, invoking religion instead of engaging with the actual technical aspects is aggressive, yes. (Also, I was employed to write documentation, not do marketing, at least be accurate if you're going to try and smear me.)
        2y ago
- immibis 2y ago
  They said it, but it's a platitude - a lie. If this results in a broken kernel because the Rust part was not updated, the C change will be reverted to get a working kernel. This makes C maintainers de facto responsible for learning Rust to update the bindings.
  - steveklabnik 2y ago
    That is simply not true. That is why Rust is an experiment currently: it is allowed to break. Compiling the Rust code at all requires an extra flag to be passed, so breaking Rust code never breaks normal builds.
    - immibis 2y ago
      This is already the treatment given to out of tree kernel modules. Why not do the experiment out of tree?
      - steveklabnik 2y ago
        Rust has already demonstrated its usefulness out of tree, with stuff like binder in Android and the GPU driver for the M1 with Asahi Linux. With those successes, upstream is interested in seeing what Rust in-tree would look like. Hence the in-tree experimentation going on now.
  - Pet_Ant 2y ago
    They don't need to learn Rust. They could reach out and get help from someone that does. I'm sure the Rusteceans would be happy to if it got more support for C.
- RandomThoughts3 2y ago
  I don’t particularly care about this discussion and I’m overall fairly sympathetic to what Rust tries to achieve but some of the claims made on the Linux ML by Rust zealots don’t help them. Memory safety through life cycle tracking is not the be-all end-all perfect solution to issues that some proponents paint especially in the kernel context and constantly painting C developers are irresponsible is probably not the wisest choice as a convincing strategy.
  - steveklabnik 2y ago
    I am simply stating the facts of the situation, if you think that means that the C folks are irresponsible, that’s on you. I do not think the C folks are being irresponsible. I think some of the C people are being obstinate, and deliberately trying to interfere with the experiment Linus asked to be carried out. There are others who have been quite supportive!
    - RandomThoughts3 2y ago
      > I am simply stating the facts of the situation No, you are not. You are presenting your interpretation of the facts implying it’s truth in a way which is entirely typical of how Rust outreach has always been done. As usual, it’s more about emotion that facts. If you bring the Ruby playbook to a kernel discussion, you are not going to be well received. Anyway, let me bit this bullet regarding the irresponsible comment: "But I get the feeling that some Linux kernel maintainers just don't care about future code quality, or about stability or security any more […] They just want to keep their C code and wish us Rust folks would go away. And that's really sad... and isn't helping make Linux better." Asahi Lina
      - steveklabnik 2y ago
        That the Rust code is allowed to break, and that the Rust for Linux folks have agreed to fix it so that nobody who doesn't want to write Rust does not have to write Rust, is a fact.
        2y ago

steveklabnik 2y ago

> ensure C code changes do not break Rust code This is not true. C code is allowed to break Rust bindings. The Rust For Linux folks will then go fix it. The C side was repeatedly told this, but doesn’t seem to want to hear it.

janice1999 2y ago
As far as I understand it, that is only in the short term for the file system experiment where Rust is a "second class citizen" as Ted T'so put it.
- steveklabnik 2y ago
  Nobody has decided what the post-experiment policy will be. A second language is new grounds for the kernel. Ted is assuming in order to interfere with the experiment.
anon-3988 2y ago
> The Rust For Linux folks will then go fix it. Doesn't this mean that the change will have to be blocked until the Rust side is also fixed? Rust folks are eager to do it now, and there's a lot of "hype" around having Rust but is it going to be the same in, say, 15 years? Userspace Rust is awesome ( aside from being a bit big), but I don't know if Rust in the kernel is proven yet (Time will literally tell).
- steveklabnik 2y ago
  No. It specifically is being treated as a second class citizen that is allowed to break. Rust is already in the Windows kernel. It’s being used in embedded devices and kernels in production. It has proven itself.
- estebank 2y ago
  > but is it going to be the same in, say, 15 years? You would think that by then either the Rust experiment has failed or the project has gained enough experienced developers such that maintaining such large refactors is feasible beyond heroics of the RfL folks. Either way it would be unlikely to be a problem then. But in the meantime, how is the Linux project meant to evaluate what the maintenance burden is or wether the benefits outright the costs if the kernel maintainers doing the RfL work are being repeatedly stonewalled?
JohnFen 2y ago
A lot of that might have something to do with the fact that the Rust community is incredibly hostile to the C community.
- steveklabnik 2y ago
  Can you show me where this is happening in the Linux project? I’ve only ever seen hostility from the C folks to the Rust folks. I agree that in general the overall level of hostility in the kernel seems higher than ideal.
  - RandomThoughts3 2y ago
    With all due respect, you might not be completely neutral and unbiased here.
    - steveklabnik 2y ago
      Then show me the evidence. You also say “Rust zealots” above so you yourself (like frankly everyone) have bias as well.
      - RandomThoughts3 2y ago
        You are the one implying the C developers are aggressing the Rust crowd, mr formerly professionally employed by the Rust project for outreach person.
        steveklabnik 2y ago
        Everyone is free to watch the video and make up their own minds, invoking religion instead of engaging with the actual technical aspects is aggressive, yes. (Also, I was employed to write documentation, not do marketing, at least be accurate if you're going to try and smear me.)
        2y ago
immibis 2y ago
They said it, but it's a platitude - a lie. If this results in a broken kernel because the Rust part was not updated, the C change will be reverted to get a working kernel. This makes C maintainers de facto responsible for learning Rust to update the bindings.
- steveklabnik 2y ago
  That is simply not true. That is why Rust is an experiment currently: it is allowed to break. Compiling the Rust code at all requires an extra flag to be passed, so breaking Rust code never breaks normal builds.
  - immibis 2y ago
    This is already the treatment given to out of tree kernel modules. Why not do the experiment out of tree?
    - steveklabnik 2y ago
      Rust has already demonstrated its usefulness out of tree, with stuff like binder in Android and the GPU driver for the M1 with Asahi Linux. With those successes, upstream is interested in seeing what Rust in-tree would look like. Hence the in-tree experimentation going on now.
- Pet_Ant 2y ago
  They don't need to learn Rust. They could reach out and get help from someone that does. I'm sure the Rusteceans would be happy to if it got more support for C.
RandomThoughts3 2y ago
I don’t particularly care about this discussion and I’m overall fairly sympathetic to what Rust tries to achieve but some of the claims made on the Linux ML by Rust zealots don’t help them. Memory safety through life cycle tracking is not the be-all end-all perfect solution to issues that some proponents paint especially in the kernel context and constantly painting C developers are irresponsible is probably not the wisest choice as a convincing strategy.
- steveklabnik 2y ago
  I am simply stating the facts of the situation, if you think that means that the C folks are irresponsible, that’s on you. I do not think the C folks are being irresponsible. I think some of the C people are being obstinate, and deliberately trying to interfere with the experiment Linus asked to be carried out. There are others who have been quite supportive!
  - RandomThoughts3 2y ago
    > I am simply stating the facts of the situation No, you are not. You are presenting your interpretation of the facts implying it’s truth in a way which is entirely typical of how Rust outreach has always been done. As usual, it’s more about emotion that facts. If you bring the Ruby playbook to a kernel discussion, you are not going to be well received. Anyway, let me bit this bullet regarding the irresponsible comment: "But I get the feeling that some Linux kernel maintainers just don't care about future code quality, or about stability or security any more […] They just want to keep their C code and wish us Rust folks would go away. And that's really sad... and isn't helping make Linux better." Asahi Lina
    - steveklabnik 2y ago
      That the Rust code is allowed to break, and that the Rust for Linux folks have agreed to fix it so that nobody who doesn't want to write Rust does not have to write Rust, is a fact.
      - 2y ago