6 ms·

How many times will this need to be said: the Rust maintainers have committed to handling all maintenance of Rust code, and handling all breakage of their code

How many times will this need to be said: the Rust maintainers have committed to handling all maintenance of Rust code, and handling all breakage of their code by changes on the C side. The only "burden" the C maintainers have to carry is to CC a couple of extra people on commits when APIs change.

uecker 2y ago
I don't think it is this simple.
afr0ck 2y ago
This is not how the kernel works. You cannot rely on someone's "commitment" or "promise". Kernel maintainers was to have very good control over the kernel and they want strong separation of concern. As long as this is not delivered, it will be very hard to accept the Rust changes.
- dralley 2y ago
  At some level this is just concern trolling. There is nothing the Rust developers could possibly do or say that would alleviate the concern you've just expressed. You are asking for something that is impossible. What could they possibly "deliver" beyond a strong commitment to fix the code in a timely manner themselves?
  - tmoertel 2y ago
    > There is nothing the Rust developers could possibly do or say that would alleviate the concern you've just exprssed. They could do exactly what Ted Ts'o suggested in his email [1] that Marcan cited: They could integrate more into the existing kernel-development community, contribute to Linux in general, not just in relation to their pet projects, and over time earn trust that, when they make promises with long time horizons, they can actually keep them. Because, if they can't keep those promises, whoever lets their code into the kernel ends up having to keep their promises for them. [1] https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.edu/ https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed...
    - dralley 2y ago
      Many of them have, in fact, done all of those things, and have done them over a time horizon measured in years. Many of the R4L developers are paid by their employers specifically to work on R4L and can therefore be considered reasonably reliable and not drive-by contributors. Many existing maintainers are not "general contributors" It is unreasonable (and a recipe for long-term project failure) to expect every new contributor to spend years doing work they don't want to do (and are not paid to do) before trusting them to work on the things they do want (and are paid) to do. Christoph refused to take onboard a new maintainer. The fight from last August was about subsystem devs refusing to document the precise semantics of their C APIs. These are signs of fief-building that would be equally dangerous to the long-term health of the project if Rust was not involved whatsoever.
      - zifpanachr23 2y ago
        I disagree. If you want to provide technical leadership by massively changing the organization and tooling of a huge project that has been around a long time, it should be absolutely mandatory to spend years building trust and doing work that you don't want to do. That's just how programming on teams and trust and teamwork actually works in the real world. Especially on a deadly serious not-hobby project like the kernel. Sometimes you are gonna have to do work that doesn't excite you. That's life doing professional programming. Everything Ted Tso recommended is just common sense teamwork 101 stuff and it's just generally good advice for programmers in their careers. The inability of rust people to follow it will only hurt them and doom their desire to be accepted by larger more important projects in the long run. Programming on a team is a social affair and pretending you don't have to play by the rules because you have such great technical leadership is arrogant.
        dralley 2y ago
        Wedson had been working in the kernel for 4.5 years!
      - account42 2y ago
        > It is unreasonable (and a recipe for long-term project failure) to expect every new contributor to spend years doing work they don't want to do (and are not paid to do) before trusting them to work on the things they do want (and are paid) to do. It is absolutely reasonable if the work they want to do is to refactor the entire project.
  - lostdog 2y ago
    It is not concern trolling. It is a harsh disagreement. Some kernel developers really do feel that any Rust in the kernel will eventually mean that Rust gets accepted as a kernel language, and that they will eventually have to support it, and they the only way to prevent this is to stop any Rust development right now. And yes, there's nothing that the R4L group can offer to be get around that belief. There isn't any compromise on this. Either Rust is tried, then spreads, then is accepted, or it's snuffed out right now. A big mistake by R4L people is seeing anti-Rust arguments as "unfair" and "nontechnical." But it is a highly technical argument about the health of the project (though sometimes wrapped in abusive language). Rust is very scary, and calling out scared people as being unfair is not effective.
    - dralley 2y ago
      OP said "As long as this is not delivered" There is nothing to deliver that would satisfy this argument. Pretending like the disagreement is about a failure of the R4L folks to do "enough" when in fact there is nothing they could do is toxic behavior. If you go back digging in the LKML archives, Christoph's initial response to Rust was more of a "let's prove it can be useful first with some drivers" https://lore.kernel.org/lkml/YOVNJuA0ojmeLvKa@infradead.org/ https://lore.kernel.org/lkml/YOVNJuA0ojmeLvKa@infradead.org/ https://lore.kernel.org/lkml/YOW2auE24e888TBE@infradead.org/ https://lore.kernel.org/lkml/YOW2auE24e888TBE@infradead.org/ That has now been done. People (particularly Marcan) spent thousands of hours writing complex and highly functional drivers in Rust and proved out the viability, and now the goalposts are being moved. R4L people are allowed to get upset about people playing lucy-with-the-football like this wasting their f***ing time.
      - lostdog 2y ago
        Yeah, that's an interesting point that even Christoph sounded open to it in the past. Thank you!
  - zifpanachr23 2y ago
    To start, not resigning when things don't go their way. That tendency is doing a lot to make the claim of rust people saying they will handle the burden of rust code unbelievable.
  - bombcar 2y ago
    The standard procedure is to maintain a fork/patchset that does what you want and you maintain it for years proving that you will do the work you committed to. Once it’s been around long enough, it has a much better chance of being merged to main.
    - dralley 2y ago
      That has already been the case with Asahi Linux - for years. It exists as a series of forked packages. The thing is, you do still have to present a light at the end of the tunnel. If, after years of time investment and proven commitment, you're still being fed a bunch of non-technical BS excuses and roadblocks, people are going to start getting real upset.
    - dwaite 2y ago
      However, it may only get merged in by being conceptually re-thought and reimplemented, like the Linux USB or KGI projects back in the day. The general pushback for changes in Linux are against large impactful changes. They want your code to be small fixes they can fully understand, or drivers that can be excluded from the build system if they start to crash or aren't updated to a new API change. You can't take a years-maintained external codebase and necessarily convert it to an incremental stream of small patches and optional features for upstream maintainers, unless you knew to impose that sort of restriction on yourself as a downstream maintainer.
rc00 2y ago
As of today, the burden is uncertain and the Rust crowd has not been fixing things quickly enough since they are manual fixes: https://lore.kernel.org/rust-for-linux/20250131135421.GO5556@nvidia.com/ https://lore.kernel.org/rust-for-linux/20250131135421.GO5556... > Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not. > Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders". > It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build. For clarity, tree-wide fixes for C in the kernel are automated via Coccinelle. Coccinelle for Rust is constantly unstable and broken which is why manual fixes are required. Does this help to explain the burden that C developers are facing because of Rust and how it is in addition to their existing workloads?
- chrsig 2y ago
  > For clarity, tree-wide fixes for C in the kernel are automated via Coccinelle. Coccinelle for Rust is constantly unstable and broken which is why manual fixes are required. Does this help to explain the burden that C developers are facing because of Rust and how it is in addition to their existing workloads? Yes actually, I really wish someone would bring that sort of thing to the forefront, because that's a great spot to welcome new contributors.
toast0 2y ago
As a non-interested observer; I think it will need to be said until the commitment becomes credible. I don't know how it would become credible, but it's clearly not considered credible by at least those of the kernel maintainers who are worried about the maintenance burden of accepting rust patches.
gkbrk 2y ago
This is not what the "Rust kernel policy" [1] of Rust for Linux says. [1]: https://rust-for-linux.com/rust-kernel-policy https://rust-for-linux.com/rust-kernel-policy > Who is responsible if a C change breaks a build with Rust enabled? > The usual kernel policy applies. So, by default, changes should not be introduced if they are known to break the build, including Rust. > Didn't you promise Rust wouldn't be extra work for maintainers? > No, we did not. Since the very beginning, we acknowledged the costs and risks a second language introduces.
- steveklabnik 2y ago
  You conveniently left out > However, exceptionally, for Rust, a subsystem may allow to temporarily break Rust code. The intention is to facilitate friendly adoption of Rust in a subsystem without introducing a burden to existing maintainers who may be working on urgent fixes for the C side. The breakage should nevertheless be fixed as soon as possible, ideally before the breakage reaches Linus.
  - gkbrk 2y ago
    Yes, "breakage should be fixed as soon as possible". Not "Rust for Linux team will fix the breakage as soon as possible". The exception is allowing the subsystem to break Rust code temporarily. If you accept a patch in C that breaks Rust code, and the Rust for Linux team doesn't fix it quickly enough, you either need to fix the Rust code yourself, remove it, or re-write it in C. All of this would take time and energy from all the non-R4L kernel devs. This is why people are reluctant to accept too much mixing of the C and Rust codebases, because even the Rust for Linux team isn't promising to fix breakages in Rust for Linux code.
    - nindalf 2y ago
      Just to be clear, this is the situation. A rando submits a C patch that breaks Rust code, a maintainer accepts this patch and then demands that the R4L devs fix the breakage introduced by someone else and reviewed by themselves. The rando who broke the thing isn't around, and the person who reviewed the change takes no responsibility. Have I gotten that right? And then you're presenting this situation as "the Rust for Linux team isn't promising to fix breakages in Rust for Linux code". Somewhat disingenuous.
zifpanachr23 2y ago
They've said that, but nobody believes them, and can you blame them given we JUST saw another big rust maintainer resign? I'd be suspicious these guys aren't in it for the long haul if they don't get their way and will leave the Rust they shoved in the kernel to bit rot if things don't go their way w.r.t enough rust adoption fast enough. "If you don't let us add even more rust, we will resign from the project and leave you to maintain the rust that's already there and that we added, and that you said you didn't want to add because you didn't trust us to not resign". Rust 4 Linux people just proving the points of the maintainers scared of abandonment. The rust 4 Linux people unfortunarely give the impression of caring more about rust than about the kernel, and it's clear that many are willing to make that perfectly clear by abandoning the larger project. The whole thing needs to be scrapped and rethought with better and more committed leadership. This past 6 months to a year has been embarrassing and done nothing but confirm the fears of anti rust people.
- timeon 2y ago
  These people were quitting after being harassed. So I do not think you are arguing in good faith.
aragilar 2y ago
That doesn't line with https://rust-for-linux.com/rust-kernel-policy#who-is-responsible-if-a-c-change-breaks-a-build-with-rust-enabled https://rust-for-linux.com/rust-kernel-policy#who-is-respons... (which may be a recent change?)
CRConrad 2y ago
> the Rust maintainers have committed to handling all maintenance of Rust code, and handling all breakage of their code by changes on the C side. How have they "committed"? By saying they commit[1], I presume -- but what more? Anyone can say anything. I think what makes the "old guard" kernel maintainers nervous is the lack of a track record. And yes, I know that's a kind of a lifting-yourself-by-your-bootstraps problem. And no, I don't know of any solution to that. But I do know that, like baron Münchhausen, you can't ride your high horse around the swamp before you've pulled your self out of it. ___ [1]: And, as others in this thread have shown, that's apparently just out of one side of their collective mouth: The official "Rust kernel policy" says otherwise.

uecker 2y ago

I don't think it is this simple.

afr0ck 2y ago

This is not how the kernel works. You cannot rely on someone's "commitment" or "promise". Kernel maintainers was to have very good control over the kernel and they want strong separation of concern. As long as this is not delivered, it will be very hard to accept the Rust changes.

dralley 2y ago
At some level this is just concern trolling. There is nothing the Rust developers could possibly do or say that would alleviate the concern you've just expressed. You are asking for something that is impossible. What could they possibly "deliver" beyond a strong commitment to fix the code in a timely manner themselves?
- tmoertel 2y ago
  > There is nothing the Rust developers could possibly do or say that would alleviate the concern you've just exprssed. They could do exactly what Ted Ts'o suggested in his email [1] that Marcan cited: They could integrate more into the existing kernel-development community, contribute to Linux in general, not just in relation to their pet projects, and over time earn trust that, when they make promises with long time horizons, they can actually keep them. Because, if they can't keep those promises, whoever lets their code into the kernel ends up having to keep their promises for them. [1] https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.edu/ https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed...
  - dralley 2y ago
    Many of them have, in fact, done all of those things, and have done them over a time horizon measured in years. Many of the R4L developers are paid by their employers specifically to work on R4L and can therefore be considered reasonably reliable and not drive-by contributors. Many existing maintainers are not "general contributors" It is unreasonable (and a recipe for long-term project failure) to expect every new contributor to spend years doing work they don't want to do (and are not paid to do) before trusting them to work on the things they do want (and are paid) to do. Christoph refused to take onboard a new maintainer. The fight from last August was about subsystem devs refusing to document the precise semantics of their C APIs. These are signs of fief-building that would be equally dangerous to the long-term health of the project if Rust was not involved whatsoever.
    - zifpanachr23 2y ago
      I disagree. If you want to provide technical leadership by massively changing the organization and tooling of a huge project that has been around a long time, it should be absolutely mandatory to spend years building trust and doing work that you don't want to do. That's just how programming on teams and trust and teamwork actually works in the real world. Especially on a deadly serious not-hobby project like the kernel. Sometimes you are gonna have to do work that doesn't excite you. That's life doing professional programming. Everything Ted Tso recommended is just common sense teamwork 101 stuff and it's just generally good advice for programmers in their careers. The inability of rust people to follow it will only hurt them and doom their desire to be accepted by larger more important projects in the long run. Programming on a team is a social affair and pretending you don't have to play by the rules because you have such great technical leadership is arrogant.
      - dralley 2y ago
        Wedson had been working in the kernel for 4.5 years!
    - account42 2y ago
      > It is unreasonable (and a recipe for long-term project failure) to expect every new contributor to spend years doing work they don't want to do (and are not paid to do) before trusting them to work on the things they do want (and are paid) to do. It is absolutely reasonable if the work they want to do is to refactor the entire project.
- lostdog 2y ago
  It is not concern trolling. It is a harsh disagreement. Some kernel developers really do feel that any Rust in the kernel will eventually mean that Rust gets accepted as a kernel language, and that they will eventually have to support it, and they the only way to prevent this is to stop any Rust development right now. And yes, there's nothing that the R4L group can offer to be get around that belief. There isn't any compromise on this. Either Rust is tried, then spreads, then is accepted, or it's snuffed out right now. A big mistake by R4L people is seeing anti-Rust arguments as "unfair" and "nontechnical." But it is a highly technical argument about the health of the project (though sometimes wrapped in abusive language). Rust is very scary, and calling out scared people as being unfair is not effective.
  - dralley 2y ago
    OP said "As long as this is not delivered" There is nothing to deliver that would satisfy this argument. Pretending like the disagreement is about a failure of the R4L folks to do "enough" when in fact there is nothing they could do is toxic behavior. If you go back digging in the LKML archives, Christoph's initial response to Rust was more of a "let's prove it can be useful first with some drivers" https://lore.kernel.org/lkml/YOVNJuA0ojmeLvKa@infradead.org/ https://lore.kernel.org/lkml/YOVNJuA0ojmeLvKa@infradead.org/ https://lore.kernel.org/lkml/YOW2auE24e888TBE@infradead.org/ https://lore.kernel.org/lkml/YOW2auE24e888TBE@infradead.org/ That has now been done. People (particularly Marcan) spent thousands of hours writing complex and highly functional drivers in Rust and proved out the viability, and now the goalposts are being moved. R4L people are allowed to get upset about people playing lucy-with-the-football like this wasting their f***ing time.
    - lostdog 2y ago
      Yeah, that's an interesting point that even Christoph sounded open to it in the past. Thank you!
- zifpanachr23 2y ago
  To start, not resigning when things don't go their way. That tendency is doing a lot to make the claim of rust people saying they will handle the burden of rust code unbelievable.
- bombcar 2y ago
  The standard procedure is to maintain a fork/patchset that does what you want and you maintain it for years proving that you will do the work you committed to. Once it’s been around long enough, it has a much better chance of being merged to main.
  - dralley 2y ago
    That has already been the case with Asahi Linux - for years. It exists as a series of forked packages. The thing is, you do still have to present a light at the end of the tunnel. If, after years of time investment and proven commitment, you're still being fed a bunch of non-technical BS excuses and roadblocks, people are going to start getting real upset.
  - dwaite 2y ago
    However, it may only get merged in by being conceptually re-thought and reimplemented, like the Linux USB or KGI projects back in the day. The general pushback for changes in Linux are against large impactful changes. They want your code to be small fixes they can fully understand, or drivers that can be excluded from the build system if they start to crash or aren't updated to a new API change. You can't take a years-maintained external codebase and necessarily convert it to an incremental stream of small patches and optional features for upstream maintainers, unless you knew to impose that sort of restriction on yourself as a downstream maintainer.

rc00 2y ago

As of today, the burden is uncertain and the Rust crowd has not been fixing things quickly enough since they are manual fixes: https://lore.kernel.org/rust-for-linux/20250131135421.GO5556@nvidia.com/ https://lore.kernel.org/rust-for-linux/20250131135421.GO5556... > Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not. > Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders". > It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build. For clarity, tree-wide fixes for C in the kernel are automated via Coccinelle. Coccinelle for Rust is constantly unstable and broken which is why manual fixes are required. Does this help to explain the burden that C developers are facing because of Rust and how it is in addition to their existing workloads?

chrsig 2y ago
> For clarity, tree-wide fixes for C in the kernel are automated via Coccinelle. Coccinelle for Rust is constantly unstable and broken which is why manual fixes are required. Does this help to explain the burden that C developers are facing because of Rust and how it is in addition to their existing workloads? Yes actually, I really wish someone would bring that sort of thing to the forefront, because that's a great spot to welcome new contributors.

toast0 2y ago

As a non-interested observer; I think it will need to be said until the commitment becomes credible. I don't know how it would become credible, but it's clearly not considered credible by at least those of the kernel maintainers who are worried about the maintenance burden of accepting rust patches.

gkbrk 2y ago

This is not what the "Rust kernel policy" [1] of Rust for Linux says. [1]: https://rust-for-linux.com/rust-kernel-policy https://rust-for-linux.com/rust-kernel-policy > Who is responsible if a C change breaks a build with Rust enabled? > The usual kernel policy applies. So, by default, changes should not be introduced if they are known to break the build, including Rust. > Didn't you promise Rust wouldn't be extra work for maintainers? > No, we did not. Since the very beginning, we acknowledged the costs and risks a second language introduces.

steveklabnik 2y ago
You conveniently left out > However, exceptionally, for Rust, a subsystem may allow to temporarily break Rust code. The intention is to facilitate friendly adoption of Rust in a subsystem without introducing a burden to existing maintainers who may be working on urgent fixes for the C side. The breakage should nevertheless be fixed as soon as possible, ideally before the breakage reaches Linus.
- gkbrk 2y ago
  Yes, "breakage should be fixed as soon as possible". Not "Rust for Linux team will fix the breakage as soon as possible". The exception is allowing the subsystem to break Rust code temporarily. If you accept a patch in C that breaks Rust code, and the Rust for Linux team doesn't fix it quickly enough, you either need to fix the Rust code yourself, remove it, or re-write it in C. All of this would take time and energy from all the non-R4L kernel devs. This is why people are reluctant to accept too much mixing of the C and Rust codebases, because even the Rust for Linux team isn't promising to fix breakages in Rust for Linux code.
  - nindalf 2y ago
    Just to be clear, this is the situation. A rando submits a C patch that breaks Rust code, a maintainer accepts this patch and then demands that the R4L devs fix the breakage introduced by someone else and reviewed by themselves. The rando who broke the thing isn't around, and the person who reviewed the change takes no responsibility. Have I gotten that right? And then you're presenting this situation as "the Rust for Linux team isn't promising to fix breakages in Rust for Linux code". Somewhat disingenuous.

zifpanachr23 2y ago

They've said that, but nobody believes them, and can you blame them given we JUST saw another big rust maintainer resign? I'd be suspicious these guys aren't in it for the long haul if they don't get their way and will leave the Rust they shoved in the kernel to bit rot if things don't go their way w.r.t enough rust adoption fast enough. "If you don't let us add even more rust, we will resign from the project and leave you to maintain the rust that's already there and that we added, and that you said you didn't want to add because you didn't trust us to not resign". Rust 4 Linux people just proving the points of the maintainers scared of abandonment. The rust 4 Linux people unfortunarely give the impression of caring more about rust than about the kernel, and it's clear that many are willing to make that perfectly clear by abandoning the larger project. The whole thing needs to be scrapped and rethought with better and more committed leadership. This past 6 months to a year has been embarrassing and done nothing but confirm the fears of anti rust people.

timeon 2y ago
These people were quitting after being harassed. So I do not think you are arguing in good faith.

aragilar 2y ago

That doesn't line with https://rust-for-linux.com/rust-kernel-policy#who-is-responsible-if-a-c-change-breaks-a-build-with-rust-enabled https://rust-for-linux.com/rust-kernel-policy#who-is-respons... (which may be a recent change?)

CRConrad 2y ago

> the Rust maintainers have committed to handling all maintenance of Rust code, and handling all breakage of their code by changes on the C side. How have they "committed"? By saying they commit[1], I presume -- but what more? Anyone can say anything. I think what makes the "old guard" kernel maintainers nervous is the lack of a track record. And yes, I know that's a kind of a lifting-yourself-by-your-bootstraps problem. And no, I don't know of any solution to that. But I do know that, like baron Münchhausen, you can't ride your high horse around the swamp before you've pulled your self out of it. ___ [1]: And, as others in this thread have shown, that's apparently just out of one side of their collective mouth: The official "Rust kernel policy" says otherwise.