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