• vanderbilt@lemmy.world
    link
    fedilink
    arrow-up
    20
    arrow-down
    7
    ·
    2 days ago

    Fact is Rust isn’t ready for every part of the kernel. C/Rust interop is still a growing pain for Linux and troubleshooting issues at the boundary require a developer to be good at both. It’s an uphill battle, and instead of inciting flame wars they could have fostered cooperation around the parts of the kernel that were more prepared. While their work is appreciated and they are incredibly talented, the reality is that social pressures are going to dictate development. At the end of the day software is used by people. Their expectations are not law, but they do need addressed to preserve public opinion.

    • FooBarrington@lemmy.world
      link
      fedilink
      arrow-up
      36
      arrow-down
      5
      ·
      2 days ago

      Again: what cooperation is possible when the maintainer says “I’ll do everything in my power to keep Rust out of the kernel”? When they NACK a patch outside of their Subsystem?

      • aksdb@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        1 day ago

        Can a maintainer really NACK any patch they dislike? I mean I get that Hellwig said he won’t merge it. Fine. What if for example Kroah-Hartman says “whatever, I like it” and merges it nonetheless in his tree?

        • LeFantome@programming.dev
          link
          fedilink
          arrow-up
          3
          ·
          1 day ago

          I doubt Greg is pulling in Rust until it has been through the mainline. That said, Linus can merge anything he wants.

          • aksdb@lemmy.world
            link
            fedilink
            arrow-up
            2
            ·
            1 day ago

            It was an example. I don’t have a fucking clue how all the maintainers are named.

            The main question was: why can a maintainer NACK something not in their responsibility? Isn’t it simply necessary to find one maintainer who is fine with it and pulls it in?

            Or even asked differently: shouldn’t you need to find someone who ACKs it rather than caring about who NACKs it?

        • catloaf@lemm.ee
          link
          fedilink
          English
          arrow-up
          1
          ·
          22 hours ago

          Yes, but asking him in this case was basically a courtesy, the code isn’t going into anything he manages. He can reject it, but that’s an opinion, not a decision. It can still be merged if the regular maintainer (or someone senior like Linus himself) approves.

      • Tgo_up@lemm.ee
        link
        fedilink
        English
        arrow-up
        4
        arrow-down
        9
        ·
        1 day ago

        Can you quote where that was said?

        I’ve been following this debate for a bit and as far as I can tell it’s not so much that they’ll do what they can to keep rust out but more to make sure that the people who want to develop in rust are the ones who end up maintaining that part of the code and not the current maintainers.

        • FooBarrington@lemmy.world
          link
          fedilink
          arrow-up
          25
          arrow-down
          1
          ·
          edit-2
          1 day ago

          Sure: https://lore.kernel.org/rust-for-linux/[email protected]/

          I accept that you don’t want to be involved with Rust in the kernel, which is why we offered to maintain the Rust abstraction layer for the DMA coherent allocator as a separate component (which it would be anyways) ourselves.

          Which doesn’t help me a bit. Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this.

          Can’t get more explicit than this.