• Gayhitler@lemmy.ml
    link
    fedilink
    English
    arrow-up
    57
    arrow-down
    1
    ·
    8 hours ago

    https://lore.kernel.org/lkml/20250108122825.136021-1-abdiel.janulgue@gmail.com/

    Here’s the source thread.

    Tldr: someone wants to put rust in the dma part of the kernel (the part that accesses memory directly)(it’s a memory allocator abstraction layer written in rust which rust code can use directly instead of dealing with the c allocator abstraction layer), is told that rust should use the extant methods to talk to the c dma interface, replies that doing so would make rust programs that talk to dma require some more code, gets told “that’s fine. We can’t do a split codebase”. The two parties work towards some resolution, then hector martin comes in and acts like jerk and gets told to fuck off by Linus.

    Martin is no lennart poettering but I don’t try to see things from his perspective anymore.

    It’s worth noting that Linus’ “approval” of rust in the kernel isn’t generally seen as a blanket endorsement, but a willingness to see how it might go and rust people have been generally trying to jam their code everywhere using methods that rival the cia simple field sabotage manual.

    I don’t think it’s on purpose (except for maybe Martin) but a byproduct of the kernel maintainers moving slowly but surely and the rust developers moving much faster and some seeing the solution to that slow movement as jamming their foot in the door and wedging it open.

    • verdigris@lemmy.ml
      link
      fedilink
      arrow-up
      18
      arrow-down
      3
      ·
      7 hours ago

      To be fair, I’m not sure how “I will do everything in my power to oppose this” is the anti-Rust side “work[ing] towards some resolution”…

        • FooBarrington@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          55 minutes ago

          This creates a lot of extra work for no benefit, as every driver that needs DMA would have to include their own copy of the DMA stuff.

      • Gayhitler@lemmy.ml
        link
        fedilink
        English
        arrow-up
        14
        ·
        7 hours ago

        That’s tame for the kernel mailing list lol.

        The context is that hellwig doesn’t want another maintainer or deal with a split codebase in the dma subsystem which I honestly agree with.

        If I were a maintainer in that position I’d be barring the doors too. It’s not a driver for some esoteric realtek wireless card or something.

        Even if I didn’t agree with that position it’s normal to only post on the kernel mailing list about shit you actually care deeply about because it’s public and aside from all your fellow devs taking the time to read what you wrote, psychotic nerds like myself watch it and will try to read the tea leaves too!

        • FooBarrington@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          53 minutes ago

          If I were a maintainer in that position I’d be barring the doors too. It’s not a driver for some esoteric realtek wireless card or something.

          This effectively kills R4L. If they can’t include Rust Interfaces for important subsystems, each driver written in Rust that uses these subsystems has to separately track all the Subsystem Interfaces, leading to lots of extra work for no benefit.

          If this is the approach Linux takes, they should just cancel R4L completely.

        • verdigris@lemmy.ml
          link
          fedilink
          arrow-up
          3
          ·
          6 hours ago

          Sure, I don’t think it’s like toxic or anything, but I also understand why Martin viewed the situation as an impasse requiring a decision from on high. Also, from my limited understanding it sounds like the new code was in a sequestered rust-only section of the dma subsystem, so I’m not clear on exactly what new burdens were being placed on the C dma maintainers.

          • Gayhitler@lemmy.ml
            link
            fedilink
            English
            arrow-up
            2
            ·
            4 hours ago

            My understanding is that the rust code in question implemented parts of the c dma interface so that rust programs could use that instead of the c dma interface.

            I’m out in the world, not sitting in front of a computer with the source open so that guess will have to do for now.

            The most immediate problem with having two different dma interfaces is that now you have two maintainers and an extra step at best when making any changes.

        • verdigris@lemmy.ml
          link
          fedilink
          arrow-up
          5
          arrow-down
          1
          ·
          7 hours ago

          If you read the article, the main issue is not the fact that it’s Rust itself, but that it’s a second language entering the codebase. There’s definitely some validity to the argument.

          My personal view is that any C developer who doesn’t want to learn Rust is going to kick themselves once they do.

          • droplet6585@lemmy.ml
            link
            fedilink
            English
            arrow-up
            1
            ·
            22 minutes ago

            the main issue is

            Sure. But I’ve seen quite a bit of push back against rust from these sorts even outside the kernel.

    • Michael@lemmy.ml
      link
      fedilink
      arrow-up
      3
      arrow-down
      3
      ·
      edit-2
      3 hours ago

      trying to jam their code everywhere using methods that rival the cia simple field sabotage manual.

      I am aware of the manual, but I fail to see how adding to a codebase is “sabotage” if it’s all generally seen as fine by the project lead - it’s far from a hostile takeover.

      Would a CIA saboteur even want memory safety as a rule? Just speculating, but I’d say that’s unlikely.

      Edit: I changed the order of the sentences, as it was not intentionally ordered, and slightly clarified my second thought.

      • Gayhitler@lemmy.ml
        link
        fedilink
        English
        arrow-up
        4
        ·
        4 hours ago

        I don’t think the ends are those of the cia, and I didn’t say that the means were either, only that they were similar to those in a famous mid century guide for those trying to halt or hijack organizations.

        I don’t think the rust devs are a cia opp, before you ask. I think some rust devs and even proponents of rust who only cheer from the sidelines are sometimes behaving in ways that raise red flags. I think it’s natural and laudable that the existing devs and maintainers are alarmed by that same behavior. It’s their job.

        I also think Linus position on rust has been stretched to the point of breaking and I personally find it hard to take positions seriously that distill the complex process of integrating new languages into a very old very large codebase with many full time developers into “Linus said I could”.

        • Michael@lemmy.ml
          link
          fedilink
          arrow-up
          1
          arrow-down
          1
          ·
          edit-2
          3 hours ago

          Again, I am aware of the manual. I was recently exposed to it, as well, so it’s very fresh in my mind. I understand why you mentioned it and understand what you are saying, but I disagree, I don’t see the parallels.

          I think Linus just wants the drama to stop and the progress to flow, but I’ll let him speak for his emotions towards the R4L project and avoid speculating about him.

          I’m just openly speculating that there are vulnerabilities in the code, and that the R4L project will uncover those as a natural product of its evolution. I don’t think a CIA sabotage manual is apt to describe the R4L project, largely because I see it as progress. From my perspective, maintaining old C code is not something they are sabotaging.

          As opposed to the R4L members, there are those who are openly admitting to sabotaging the progress of the R4L project. If you’ve seen the past public clashes between the R4L project and the Linux kernel community, you’d also be able to garner that from those interactions as well.

          • Gayhitler@lemmy.ml
            link
            fedilink
            English
            arrow-up
            1
            ·
            3 hours ago

            It’s surprising to see that statement get brought up in the news considering it’s immediately followed by a parenthetical specifically enumerating a multi language code base as the subject not rust specifically.

            Iirc it’s even preceded by something to the effect of “I like rust, it’s good and there’s nothing wrong with projects that use it”.

            The news coverage of kernel mailing list stuff is always so needlessly breathless.

            • Michael@lemmy.ml
              link
              fedilink
              arrow-up
              1
              ·
              edit-2
              3 hours ago

              From my understanding, it’s not Hellwig’s job to maintain the Rust side of the code. They can find multi-language codebases a pain all they want and throw a gigantic tantrum focused towards the R4L project - it doesn’t affect the code that they are responsible for. I don’t see why the whole R4L project couldn’t just be removed if R4L is not maintained by those who develop and support it.

              but I will do everything I can do to stop this.

              Is an open admission of Hellwig to sabotaging the R4L project.

              Seeing the R4L folks as saboteurs or anything close is not in evidence. This isn’t the '90s, we have the means to be a lot more productive in regards to coding and managing codebases, and historical maintenance problems are irrelevant. If the R4L team is truly sabotaging the codebase by adding too much complexity or overhead, there are levers that can be pulled to change their direction without blindly rejecting or hindering their efforts.

              • Gayhitler@lemmy.ml
                link
                fedilink
                English
                arrow-up
                1
                ·
                2 hours ago

                Again, so much of the discussion around kernel mailing list exchanges excludes the context that what hellwig is talking about is not rust in the kernel at all or even r4l but a split code base.

                I dealt with a c/c++ codebase once and it was beyond my meager abilities to handle both those ostensibly similar languages at the same time and I had people who were very knowledgeable in c involved with the project.

                So when someone says “I think a split codebase is cancer to the Linux kernel” or “I will oppose this (split codebase) with all my energy” I’m like “yeah, that makes sense.”

                I also need to clarify that I don’t think anyone is sabotaging anyone else and my intent in bringing up the simple field sabotage manual was to point out that the behaviors don’t necessarily indicate sabotage but fall into a broad category of behavior that isn’t gonna solve problems or get anywhere which is why it’s included in the manual.

                I wasn’t aware it was circulating in social media recently and about fifteen years ago when I got exposed to it the main lessons to draw were not that people doing those things were active saboteurs but that those behaviors can lead to waste of energy and resources and they’re the first thing to avoid interacting with.

                My exposure to and understanding of the manual was “here are some things to avoid in your own life” not “here’s how to throw a wrench into their plans!”

                • Michael@lemmy.ml
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  edit-2
                  47 minutes ago

                  I don’t think the R4L project is for naught or is impeding progress. I see their good faith and their efforts. A split codebase can just be chopped off at the base and business can move on as usual at any point.

                  If Linux kernel maintainers are against potential improvements being found to the existing C code as a result of parallel development, then perhaps they should require the Rust developers to suggest what the added/changed code could look like in C (if possible) and their reasons for changing the implementation in Rust before they can push their implementation (forcing R4L to shoulder the brunt of the work) - or force R4L to stick to close-approximations and working within the existing system to properly change existing functionality through established processes.

                  I apologize that I misrepresented his arguments, I of course meant to say that his problem was a split codebase and I understood as much, I just misspoke. Other comments have enlightened me to better understand his arguments and concerns since I posted, as well.

                  You: […] have been generally trying to jam their code everywhere

                  I suppose your earlier statement was just stuck in my head, and I was wondering to what extent they have “infected” the codebase with Rust.

                  And I learned about the manual when a creator I was linked was talking about how there are parallels between the manual and the decline/failure of the U.S. education system, but I similarly disagreed with them that the issues of the U.S. education system are due to internal or external sabotage (through any methods described in the manual, whether intentional sabotage or not) or anything close to it. This was before Trump.

                  • Gayhitler@lemmy.ml
                    link
                    fedilink
                    English
                    arrow-up
                    1
                    ·
                    23 minutes ago

                    I don’t think that rust in the kernel is for naught or impeding progress. I think the patterns of expanding the scope of conversation to the absolutely philosophical level that some rust mailing list exchanges have done and kicking decisions up the chain or requesting a set of accommodations be made to the existing processes and methods fall broadly into the tactics outlined in the simple field sabotage manual.

                    I think it’s that behavior that isn’t going to get anywhere or solve problems.

                    I don’t think that the kernel codebase has been infected with rust. I think that especially after Linus said “sure, see what happens” to the suggestion of taking in rust work rust devs have been making tons of commits and sometimes it’s accepted, sometimes it’s rejected and often a border is created and there’s friction along it like this example.