4 ms·

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

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?

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?