4 ms·
Nope. RfL was accepted as an experiment[0], with the understanding that it CAN be ejected again if the evaluation fails. Its mandate was as an opt-in functiona
by pseudony 2y ago
Nope.
RfL was accepted as an experiment[0], with the understanding that it CAN be ejected again if the evaluation fails. Its mandate was as an opt-in functionality, primarily left for individual maintainers to decide on whether to use and leaf-nodes to use.
It is very likely that this was the very best the RfL project could hope for at that time. Had they pushed for first-class citizenship, other contributors would, sensing the impending impact on their work, likely have revolted and the proposal would have been rejected.
So here we are - this is what the RfL people of the time chose over rejection. No one is changing the game on the RfL devs - if you contribute, you are doing so knowing that this is the official state of affairs.
The problem arises because while individual device drivers and subsystem maintainers indeed can opt-in, bindings provided by RfL impact contributors and maintainers who otherwise wish to avoid using Rust. Namely, if you write Rust bindings for my subsystem and my changes break those bindings, what then ? Am I barred from maintaining my subsystem because you decided to wrap the API for a language I don't know ?
This is not the same as some C code consuming my subsystem breaks on a change, which I can easily fix. This means I now have to read those bindings, understand how they wrap my C API and how their expose API differs from mine (remember: idiomatic (fat) Rust bindings is the goal).
I am now on the hook for bindings I had no say in providing or designing?
If you don't understand how this can seem problematic, or how this can seem like maintainers are being forced into learning Rust and maintaining bindings which may well be a non-trivial layer in between the C API and consuming Rust code, then I don't know how to make the problem easier to grasp.
Essentially, it's a very simple instance of "your freedom to swing your hands ends at the point where my face begins" - someone (the RfL binding writers) are swinging their fists about, hitting some maintainers on the nose, and being surprised that said maintainers are angry about that.
[0] - https://docs.kernel.org/rust/ https://docs.kernel.org/rust/
- still_grokking 2y agoThere is a flaw in this reasoning. Nobody ever said that a subsystem maintainer needs to fix Rust bindings. As Ts'o correctly states, that's the problem of the bindings maintainers. But there is no problem at all. All that the Rust people want is to be informed about breaking changes. Also they said they're happy to get instructions on the semantics of the C APIs. They seem to want to collaborate. The C people just want them out, as it seems looking at this episode.