4 ms·

> You have a minority who wants to impose a change, and the concerns outlined in that video by the audience member reflects genuine concerns from many other mai

by simjnd 2y ago

> You have a minority who wants to impose a change, and the concerns outlined in that video by the audience member reflects genuine concerns from many other maintainers and contributors. What change exactly is being imposed? Rust has been accepted, so that parts of the kernel can be written in either Rust or C. Nobody is pushing for an entire kernel rewrite in Rust. Nobody is pushing out C maintainers. > The Rust minority has, as of yet, failed to properly answer what happens when C APIs change in either signature or semantics, either of which can break the Rust bindings. He answers in the very video: there is a process and it is communication. When a C API change which can break the Rust bindings, you email the maintainer responsible for the Rust bindings. It's as simple as that. > If broken bindings indeed can hold back changes, then C changes are held back by Rust and indeed then the onus is on the committer to either forego improving/evolving the C API or pick up Rust and fix the bindings also. In that case, yes, the Rust bindings will either freeze the C API or force the individual contributor to learn Rust. This is already happening with C development anyway, when an API change causes drivers maintained by different people to be updated, but nobody is saying "C changes are held back by C". > That people repeat their concerns isn't an expression of stupidity any more than a result of the people driving Rust into the kernel have yet to properly communicate how they envision this process to work, I suppose. But in this video, you see someone driving Rust into the kernel communicating how they envision this process to work, and a guy adopting a hostile tone claiming to be an engineer and calling another language a religion. This isn't concern, this is discrimination.

abenga 2y ago
> He answers in the very video: there is a process and it is communication. When a C API change which can break the Rust bindings, you email the maintainer responsible for the Rust bindings. It's as simple as that. This is a gross oversimplification. So after emailing, do you wait for the rust bindings to be fixed? Do you just get your changes merged regardless? Does the rust bindings maintainer have a say in what form your change takes? Can this hold back a release? > This is already happening with C development anyway,... As I understand it, the rule is if you change something that breaks other code, it is your responsibility to fix it (e.g. callers and such). This is obviously straightforward if you know C.
- CFLAddLoader 2y ago
  > This is a gross oversimplification. So after emailing, do you wait for the rust bindings to be fixed? Do you just get your changes merged regardless? Does the rust bindings maintainer have a say in what form your change takes? Can this hold back a release? I'm pretty sure they are just asking for emailing. Just a short shift to getting changes in advance some of the time rather than none of the time. It didn't sound like they were asking to cross the divide from Partition Tolerance + Availability to Partition Tolerance + Consistency, merely shifting things a step in that direction (I think the CAP theorem applies everywhere).
pseudony 2y ago
Theodore Ts'o, the person you are implying is not an engineer, started working on Linux in 1991. Just look at the MAINTAINERS file of the Linux kernel source tree. You'll find Theo maintaining several critical pieces, including leading the ext4 file system development, but really, take a look. Just to underline this. You are calling the credibility of a man whose code has most assuredly had a hand in storing your files, whether on your laptops/workstations or servers you've deployed to. A person who has been contributing for nearly *32 years*. How about we flip this around ? Here's a person who's been a large part of the success of the Linux kernel project for 32 years, and here's this presumptuous group coming in left field, telling him he's doing it all wrong and that it's time to get with the program or buzz off. People like him, the old guard, the core contributors, the main drivers of maintenance, should absolutely be heard. Linux is what it is today because of them. It's too precious to entrust to a bunch of well-meaning, but somewhat preachy and largely unproven developers. ----- So he comes off rude. But how come the people driving the Rust integration into the kernel are still ducking the hard discussion? It is almost as if everything is proceeding under the banner of "just an experiment" until, hopefully, a switch can be flipped and it becomes required, and everyone either has to maintain those bindings or see their patches rejected. Even better, then people who never wanted to pick up Rust, has to, or twiddle their thumbs in the background until some kindly soul decides to provide the updates to the bindings. Would you labor under such uncertainty and creeping adoption for a year or two, raise the points ad nauseam, get no concrete answers and NOT, at some point, lose your patience ?
- SSLy 2y ago
  > Would you labor under such uncertainty and creeping adoption for a year or two, raise the points ad nauseam, get no concrete answers and NOT, at some point, lose your patience ? Yep, that's what was happening to the RfL devs.
  - 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/

by simjnd 2y ago

abenga 2y ago

> He answers in the very video: there is a process and it is communication. When a C API change which can break the Rust bindings, you email the maintainer responsible for the Rust bindings. It's as simple as that. This is a gross oversimplification. So after emailing, do you wait for the rust bindings to be fixed? Do you just get your changes merged regardless? Does the rust bindings maintainer have a say in what form your change takes? Can this hold back a release? > This is already happening with C development anyway,... As I understand it, the rule is if you change something that breaks other code, it is your responsibility to fix it (e.g. callers and such). This is obviously straightforward if you know C.

CFLAddLoader 2y ago
> This is a gross oversimplification. So after emailing, do you wait for the rust bindings to be fixed? Do you just get your changes merged regardless? Does the rust bindings maintainer have a say in what form your change takes? Can this hold back a release? I'm pretty sure they are just asking for emailing. Just a short shift to getting changes in advance some of the time rather than none of the time. It didn't sound like they were asking to cross the divide from Partition Tolerance + Availability to Partition Tolerance + Consistency, merely shifting things a step in that direction (I think the CAP theorem applies everywhere).

pseudony 2y ago

Theodore Ts'o, the person you are implying is not an engineer, started working on Linux in 1991. Just look at the MAINTAINERS file of the Linux kernel source tree. You'll find Theo maintaining several critical pieces, including leading the ext4 file system development, but really, take a look. Just to underline this. You are calling the credibility of a man whose code has most assuredly had a hand in storing your files, whether on your laptops/workstations or servers you've deployed to. A person who has been contributing for nearly *32 years*. How about we flip this around ? Here's a person who's been a large part of the success of the Linux kernel project for 32 years, and here's this presumptuous group coming in left field, telling him he's doing it all wrong and that it's time to get with the program or buzz off. People like him, the old guard, the core contributors, the main drivers of maintenance, should absolutely be heard. Linux is what it is today because of them. It's too precious to entrust to a bunch of well-meaning, but somewhat preachy and largely unproven developers. ----- So he comes off rude. But how come the people driving the Rust integration into the kernel are still ducking the hard discussion? It is almost as if everything is proceeding under the banner of "just an experiment" until, hopefully, a switch can be flipped and it becomes required, and everyone either has to maintain those bindings or see their patches rejected. Even better, then people who never wanted to pick up Rust, has to, or twiddle their thumbs in the background until some kindly soul decides to provide the updates to the bindings. Would you labor under such uncertainty and creeping adoption for a year or two, raise the points ad nauseam, get no concrete answers and NOT, at some point, lose your patience ?

SSLy 2y ago
> Would you labor under such uncertainty and creeping adoption for a year or two, raise the points ad nauseam, get no concrete answers and NOT, at some point, lose your patience ? Yep, that's what was happening to the RfL devs.
- 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/