4 ms·

I personally have complaints about bringing rust into the Linux kernel (not a maintainer or contributor so my opinion matters very little), however making chang

by Cieric 2y ago

I personally have complaints about bringing rust into the Linux kernel (not a maintainer or contributor so my opinion matters very little), however making changes to the kernel to make it safer or more robust should always be welcome. I'm curious if this is a case of only getting a single side of the story or not though. I've heard a lot from the rust side, but nothing from the c side of the issue (obviously response is pending.) I'm going to wait on forming an opinion on the limited information currently available.

hgaskj 2y ago
[flagged]
logicchains 2y ago
I'd guess compile time would be a complaint, since Rust generally takes a lot longer to compile than equivalent C. Safety is one thing, but it isn't the be-all and end-all of kernel development; feature development is also important, and reducing productivity impacts that.
- Aeolos 2y ago
  Rust is a significantly more productive language than C. It's not even a comparison. Proof: Asahi Lina wrote an entire driver for a modern GPU, with zero reported runtime crashes, and explicitly stated this would have been impossible in C.
DSMan195276 2y ago
I've very casually followed this process (lwn articles, read a few emails) and honestly I feel like this was predictable, the problem is the maintenance cost this places on the maintainers. The kernel is developed as one whole thing, the internal C APIs get changed and those changes are applied to all the code contained in the codebase. If there's Rust code calling those APIs then it needs to be fixed as well and they don't know how to do that. Obviously you can argue over whether the need to maintain the Rust code would end up improving the C code as a result, but ultimately Linus isn't pushing hard for this to happen. Those who want Rust in the kernel need to convince those who will end up maintaining the Rust code why it's worth having, and I don't think that step has been successful.
- steveklabnik 2y ago
  > the problem is the maintenance cost this places on the maintainers. ... If there's Rust code calling those APIs then it needs to be fixed as well and they don't know how to do that. This is not the case. The C folks are allowed to break the Rust. The Rust folks are committed to fixing it. The existing maintainers do not have any extra work to do, unless you view the Rust folks saying "hey an email when you break stuff would be nice so we can fix it quickly" is extra work.
  - DSMan195276 2y ago
    > This is not the case. The C folks are allowed to break the Rust. The Rust folks are committed to fixing it. I mean sorry but that's just not realistic. What happens to that code if those maintaining the bindings/wrappers suddenly get a new job, or get tired of doing the work? It's nice (in some ways) that they've offered to maintain the Rust bindings, but it's always the maintainer's code at the end of the day. End users don't care if an FS driver is written in C or Rust, they do care if it doesn't work in a release. It's the maintainer's problem because if they break a Rust module and nobody is around to fix it they either fix it themselves or revert their changes, those are the only two options. That's basically the one hard rule Linus has - no breaking userspace. This is the case for everything in the kernel, by accepting a module or new driver the subsystem maintainer is committing to updating it as the internal APIs change, that's why there's no stable API. They're not going to be happy to allow modules and parts of their subsystem to be written in Rust just because others are promising to keep it updated, there needs to be a plan for how the maintainers can do it themselves and convince them to be willing to own it. IMO that's the only path forward. > unless you view the Rust folks saying "hey an email when you break stuff would be nice so we can fix it quickly" is extra work. What happens if they come back and say "that's too much work for us to fix in time for the next release"? I'll reiterate again that stuff being broken in a release is not acceptable, it doesn't matter _why_ it is broken.
    - steveklabnik 2y ago
      > What happens to that code if those maintaining the bindings/wrappers suddenly get a new job, or get tired of doing the work? Then the experiment will have failed, and Rust would get removed. Again, this is about a trial to see how things go. If it’s decided to be made permanent, we’ll see what the policy ends up being. But that’s a discussion for then, not now. > That's basically the one hard rule Linus has - no breaking userspace. File systems are not user space. That’s why they’re allowed to be changed to break consumers in the first place. > What happens if they come back and say "that's too much work for us to fix in time for the next release"? It is currently an experiment, and so it would end up broken for that release. That’s why it’s not considered to be more than an experiment for now. This plan is Linus approved, so it seems these tradeoffs are acceptable.

by Cieric 2y ago

hgaskj 2y ago

[flagged]

logicchains 2y ago

I'd guess compile time would be a complaint, since Rust generally takes a lot longer to compile than equivalent C. Safety is one thing, but it isn't the be-all and end-all of kernel development; feature development is also important, and reducing productivity impacts that.

Aeolos 2y ago
Rust is a significantly more productive language than C. It's not even a comparison. Proof: Asahi Lina wrote an entire driver for a modern GPU, with zero reported runtime crashes, and explicitly stated this would have been impossible in C.

DSMan195276 2y ago

I've very casually followed this process (lwn articles, read a few emails) and honestly I feel like this was predictable, the problem is the maintenance cost this places on the maintainers. The kernel is developed as one whole thing, the internal C APIs get changed and those changes are applied to all the code contained in the codebase. If there's Rust code calling those APIs then it needs to be fixed as well and they don't know how to do that. Obviously you can argue over whether the need to maintain the Rust code would end up improving the C code as a result, but ultimately Linus isn't pushing hard for this to happen. Those who want Rust in the kernel need to convince those who will end up maintaining the Rust code why it's worth having, and I don't think that step has been successful.

steveklabnik 2y ago
> the problem is the maintenance cost this places on the maintainers. ... If there's Rust code calling those APIs then it needs to be fixed as well and they don't know how to do that. This is not the case. The C folks are allowed to break the Rust. The Rust folks are committed to fixing it. The existing maintainers do not have any extra work to do, unless you view the Rust folks saying "hey an email when you break stuff would be nice so we can fix it quickly" is extra work.
- DSMan195276 2y ago
  > This is not the case. The C folks are allowed to break the Rust. The Rust folks are committed to fixing it. I mean sorry but that's just not realistic. What happens to that code if those maintaining the bindings/wrappers suddenly get a new job, or get tired of doing the work? It's nice (in some ways) that they've offered to maintain the Rust bindings, but it's always the maintainer's code at the end of the day. End users don't care if an FS driver is written in C or Rust, they do care if it doesn't work in a release. It's the maintainer's problem because if they break a Rust module and nobody is around to fix it they either fix it themselves or revert their changes, those are the only two options. That's basically the one hard rule Linus has - no breaking userspace. This is the case for everything in the kernel, by accepting a module or new driver the subsystem maintainer is committing to updating it as the internal APIs change, that's why there's no stable API. They're not going to be happy to allow modules and parts of their subsystem to be written in Rust just because others are promising to keep it updated, there needs to be a plan for how the maintainers can do it themselves and convince them to be willing to own it. IMO that's the only path forward. > unless you view the Rust folks saying "hey an email when you break stuff would be nice so we can fix it quickly" is extra work. What happens if they come back and say "that's too much work for us to fix in time for the next release"? I'll reiterate again that stuff being broken in a release is not acceptable, it doesn't matter _why_ it is broken.
  - steveklabnik 2y ago
    > What happens to that code if those maintaining the bindings/wrappers suddenly get a new job, or get tired of doing the work? Then the experiment will have failed, and Rust would get removed. Again, this is about a trial to see how things go. If it’s decided to be made permanent, we’ll see what the policy ends up being. But that’s a discussion for then, not now. > That's basically the one hard rule Linus has - no breaking userspace. File systems are not user space. That’s why they’re allowed to be changed to break consumers in the first place. > What happens if they come back and say "that's too much work for us to fix in time for the next release"? It is currently an experiment, and so it would end up broken for that release. That’s why it’s not considered to be more than an experiment for now. This plan is Linus approved, so it seems these tradeoffs are acceptable.