4 ms·

I think this is an important data point, too: Gunthorpe [nvidia]: https://lore.kernel.org/rust-for-linux/20250130154646.GA2298732@nvidia.com/ https://lore.kern

I think this is an important data point, too: Gunthorpe [nvidia]: https://lore.kernel.org/rust-for-linux/20250130154646.GA2298732@nvidia.com/ https://lore.kernel.org/rust-for-linux/20250130154646.GA2298... Basically, there is concern that even with a declaration that Rust-for-Linux devs will maintain this (and potentially every other) cross-language API translation layer file, the demarcation point between C and Rust isn't sufficient, and is causing C developers lag or headaches by having PRs rejected because of Rust-side failures. I don't see how that can be fixed without wholesale buy-in to Rust of enough kernel devs that they can fix whatever Rust problems are created by C API changes. Or Linus will have to accept PRs that break Rust-enabled builds. The R4L devs, by themselves, don't have the bandwidth to keep up. Even if they can rapidly fix problems, that adds potential friction to every C API change. Hellwig may not be communicating in a good way, but he might be right, unfortunately. Linux may need to stay as a C-only codebase until an AI language-translation tool is good enough to do things like maintain the Rust API translation layer itself. Or until basically all maintainers learn and accept Rust.

steveklabnik 2y ago
Greg replied and explained that this is a mischaracterization https://lore.kernel.org/rust-for-linux/2025013030-gummy-cosmic-7927@gregkh/ https://lore.kernel.org/rust-for-linux/2025013030-gummy-cosm...
- rc00 2y ago
  You are misrepresenting the current state. The thread was unfortunately diverted before Jason's question received an appropriate response and conclusion: 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. The matter and the question at heart is still unsettled. The answer of whether or not Rust being in a broken state is a blocker for working and valid C code will hopefully be addressed by the end of this cycle of development. Either the patches are accepted and Rust is truly allowed to be broken or the patches will not be accepted due to breaking the Rust builds. If it is the latter, as many of the C developers fear, that is the exact burden being placed upon them that they have been stressing very loudly that they have no interest in taking on. And once other maintainers see this, what is the inevitable response to this metastasization? Comments like those from Ted and Christoph will pale in comparison. The only bright side might be that this finally accelerates the inevitable demise of this failed Rust experiment so that all parties can move on with their business.
  - steveklabnik 2y ago
    Let's say that we both agree that Linus should be making clear statements here, and that lack of clarity is causing lots of problems. That one bug happened one time does not mean that the promise is broken. To be clear, it's a bad thing, but acting like this means the entire working rules are a lie is overreacting.
    - rc00 2y ago
      > That one bug happened one time does not mean that the promise is broken. It's not been once. Don't you understand that is why things have gotten to this point? Are you aware of how the developers have been using Coccinelle in their workflows and how many subsystems support it? And are you aware that the Coccinelle for Rust implementation is constantly in a dire state? Have some empathy for the folks who have had their workflows broken and burdens increased because of it. > Let's say that we both agree that Linus should be making clear statements here, and that lack of clarity is causing lots of problems. Clarity will be communicated by the result of this patch set.
      - jorvi 2y ago
        > Have some empathy for the folks who have had their workflows broken and burdens increased because of it. Okay. Will you show empathy to the R4L folks constantly having sand poured into their fuel tank by kernel maintainers?
        harshreality 2y ago
        Kernel maintainers aren't doing anything to R4L folks except where their activities intersect with the upstream linux kernel. Your analogy isn't right. R4L folks thought that preliminary R4L infrastructure being accepted upstream meant that all the changes they needed in the future would be accepted easily as well, and now that there are concerns from subsystem maintainers, a few R4L folks are playing the dramatic victim card. From what I understand, market pressures are causing R4L folks to panic. If they can't get more R4L stuff upstream, people can't ship Rust drivers, and R4L development falls apart. That's not kernel maintainers' problem, though. They have a job to do to, and it has nothing to do with Rust kernel drivers except as far as they're persuaded Rust drivers help the linux community overall and will be maintainable without unacceptably disrupting their tool-assisted workflows. Several of them have concluded, so far, that R4L PRs will unacceptably disrupt existing workflows. That's where R4L has failed. They've failed to persuade subsystem maintainers that some added headaches/retooling/efficiency-loss is worth it to enable Rust drivers. Which drivers, and who wants to use them? Perhaps the potential downstream users of those drivers can talk with kernel devs, persuade them it's really valuable, and figure out a plan?
yencabulator 2y ago
I'm not sure this is fundamentally different from e.g. a complex filesystem implementation relying on a specific MM or VFS or whatever API, and a "C developer" wanting to change that API. Just because the callers are in C doesn't necessarily make the global change easy.

steveklabnik 2y ago

Greg replied and explained that this is a mischaracterization https://lore.kernel.org/rust-for-linux/2025013030-gummy-cosmic-7927@gregkh/ https://lore.kernel.org/rust-for-linux/2025013030-gummy-cosm...

rc00 2y ago
You are misrepresenting the current state. The thread was unfortunately diverted before Jason's question received an appropriate response and conclusion: 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. The matter and the question at heart is still unsettled. The answer of whether or not Rust being in a broken state is a blocker for working and valid C code will hopefully be addressed by the end of this cycle of development. Either the patches are accepted and Rust is truly allowed to be broken or the patches will not be accepted due to breaking the Rust builds. If it is the latter, as many of the C developers fear, that is the exact burden being placed upon them that they have been stressing very loudly that they have no interest in taking on. And once other maintainers see this, what is the inevitable response to this metastasization? Comments like those from Ted and Christoph will pale in comparison. The only bright side might be that this finally accelerates the inevitable demise of this failed Rust experiment so that all parties can move on with their business.
- steveklabnik 2y ago
  Let's say that we both agree that Linus should be making clear statements here, and that lack of clarity is causing lots of problems. That one bug happened one time does not mean that the promise is broken. To be clear, it's a bad thing, but acting like this means the entire working rules are a lie is overreacting.
  - rc00 2y ago
    > That one bug happened one time does not mean that the promise is broken. It's not been once. Don't you understand that is why things have gotten to this point? Are you aware of how the developers have been using Coccinelle in their workflows and how many subsystems support it? And are you aware that the Coccinelle for Rust implementation is constantly in a dire state? Have some empathy for the folks who have had their workflows broken and burdens increased because of it. > Let's say that we both agree that Linus should be making clear statements here, and that lack of clarity is causing lots of problems. Clarity will be communicated by the result of this patch set.
    - jorvi 2y ago
      > Have some empathy for the folks who have had their workflows broken and burdens increased because of it. Okay. Will you show empathy to the R4L folks constantly having sand poured into their fuel tank by kernel maintainers?
      - harshreality 2y ago
        Kernel maintainers aren't doing anything to R4L folks except where their activities intersect with the upstream linux kernel. Your analogy isn't right. R4L folks thought that preliminary R4L infrastructure being accepted upstream meant that all the changes they needed in the future would be accepted easily as well, and now that there are concerns from subsystem maintainers, a few R4L folks are playing the dramatic victim card. From what I understand, market pressures are causing R4L folks to panic. If they can't get more R4L stuff upstream, people can't ship Rust drivers, and R4L development falls apart. That's not kernel maintainers' problem, though. They have a job to do to, and it has nothing to do with Rust kernel drivers except as far as they're persuaded Rust drivers help the linux community overall and will be maintainable without unacceptably disrupting their tool-assisted workflows. Several of them have concluded, so far, that R4L PRs will unacceptably disrupt existing workflows. That's where R4L has failed. They've failed to persuade subsystem maintainers that some added headaches/retooling/efficiency-loss is worth it to enable Rust drivers. Which drivers, and who wants to use them? Perhaps the potential downstream users of those drivers can talk with kernel devs, persuade them it's really valuable, and figure out a plan?

yencabulator 2y ago

I'm not sure this is fundamentally different from e.g. a complex filesystem implementation relying on a specific MM or VFS or whatever API, and a "C developer" wanting to change that API. Just because the callers are in C doesn't necessarily make the global change easy.