Hacker News Reader

Comment by DSMan195276 | Hacker News Reader

DSMan195276

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.

View on HN

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

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

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

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

Not discussing it now is a fatal mistake, it's the whole game. When people are told "we'll discussion ownership at a later time" all they're hearing is "this is going to be my problem in the future, so I better express the issues I see now before it becomes more widely used".

But again there's really no discussion to be had on "policy" because it's already known, there's no world where the Rust bindings can simply be left broken if it's used for anything semi-important.

> File systems are not user space. That’s why they’re allowed to be changed to break consumers in the first place.

I think you misunderstood me? I'm saying that a filesystem driver being missing from a release breaks userspace stuff that relies on that filesystem being supported. IE. a user can't access their files because the driver is not there. Linus doesn't allow changes to the kernel that breaks something like that, the reason it broken is irrelevant. It won't matter if the reason is "nobody updated the Rust bindings", that's your problem because you made the code change that broke them.

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

"There's nothing more permanent than a temporary solution". Again that's simply not a realistic view. As soon as it gets used for something the idea of not maintaining it gets significantly more complicated.

All I can say is, take it up with Linus. I think "let's see if this even works before we hash out policy" is a far more reasonable approach than "let's argue over every last bit of this before we see if it's even feasible." Others are free to disagree, of course, but that doesn't really change that this is the plan.

No one can deny that kernel devs have a valid complain and concerns. Of course Rust and Linux can work together and is feasible, on paper, and everybody wants to see it in the mainline someday.

But in reality working for and with the kernel is more than just writing code. And being realistic, you wouldn't base months worth of work on the hands and the will of some coder that may or may not have your interests in mind that week. Would you?

All work involves working with requirements or people that may change over time.

Reply on news.ycombinator.com