3 ms·
I fail to see how this is a relevant question and "the real issue" with respect to Rust. How is this situation any different from a pure C kernel? There are a
by drpossum 2y ago
I fail to see how this is a relevant question and "the real issue" with respect to Rust. How is this situation any different from a pure C kernel? There are already protocols on how this gets handled - maintain backwards compatibility and notify other maintainers of your changes, anticipated migration requirements, and any deprecations. To which the responsibility falls on the other maintainers C, Rust, or otherwise.
- lokar 2y agoIn practice (in general, not Linux specifically), you can make it all much faster and simpler by sending out the fixes for your change to impacted users. The ability to do this makes it much easier to change your api.
- drpossum 2y agoExcept we are talking about Linux specifically, the "users" here in your analogy are people working in the collective kernel code, and there is a unique culture and set of practices around maintaining this because it's not some REST API where if something breaks you just shove a bug fix out for your part.
- lokar 2y agoCertainly APIs exposed to userspace can’t ever break. But if a change can be completely hidden by fixing everything all at once (as a trivial example, renaming something) that should be ok, no?