• nous
    link
    fedilink
    English
    arrow-up
    35
    arrow-down
    1
    ·
    11 days ago

    They refuse to make changes to their C code, so it can cooperate with Rust code via bindings.

    I don’t even think the rust devs where asking for that. They are refusing changes by rust devs that help with rust while making the c code clearer and even refuse to answer questions about the semantics behind the c code. At least as far as I can see from the outside.

    • wewbull@feddit.uk
      link
      fedilink
      English
      arrow-up
      10
      arrow-down
      16
      ·
      11 days ago

      The Rust kernel devs are …

      1. …asking the maintainers to lock down APIs which the C devs purposefully leave malleable, in part, to avoid binary blob drivers being feasible.
      2. …asking maintainers to accept code into their subsystem whilst being told, you don’t need to know Rust to an expert level…trust us. Cross language interfaces always have nuance and make good attack vectors. Understandable that maintainers are cautious.
      3. …creating quite a lot of hassle for no a lot of improvement. Systems are only as resilient as their weakest components. The cross language interface is always going to be weak. Introducing a weakness to get improvements probably only succeeds at making the whole weaker.
      • FizzyOrange
        link
        fedilink
        arrow-up
        27
        ·
        11 days ago

        asking the maintainers to lock down APIs which the C devs purposefully leave malleable, in part, to avoid binary blob drivers being feasible.

        No, they were asking them to define the semantics of the filesystem APIs. Those semantics are not encoded in the C API but the Rust devs wanted to encode them in the Rust API to avoid making mistakes.

        The C devs didn’t want to, not because of concerns about binary drivers, but because the semantics are already broken. Apparently different filesystem drivers assume different semantics for the same functions and it’s a whole mess. They don’t want to face up to this and certainly don’t want anyone pointing it out, so clearly it must be the Rust devs’ fault for wanting APIs to have consistent semantics.

        The rest of your comment is nonsense.

      • lad
        link
        fedilink
        English
        arrow-up
        7
        ·
        11 days ago

        What’s the reason to avoid binary blob drivers being feasible? Is that about not being able to use non-free binary blobs in kernel? I don’t quite understand what it even is about

          • lad
            link
            fedilink
            arrow-up
            1
            ·
            11 days ago

            Got it. I agree that their drivers are (were?) of exemplary bad quality

            But I don’t think that it is realistically possible to drop all the proprietary firmware blobs, and if it’s not maybe it’s better to not actively sabotage something to ‘avoid those being feasible’?

            • Vilian@lemmy.ca
              link
              fedilink
              arrow-up
              2
              ·
              10 days ago

              Firmware don’t link to the kernel tho, and the kernel functions aren’t stable so a firmware today would stop working tomorrow because a function was refactored(and all the code in the kernel that depend on that function) for performance or security, and the binary can’t be refactored so it become useless

      • refalo
        link
        fedilink
        arrow-up
        3
        arrow-down
        6
        ·
        11 days ago

        IIRC They were also trying to get kernel devs to let official structure definitions live in Rust instead of C, and got upset when they didn’t want to do that.

        • Pup Biru@aussie.zone
          link
          fedilink
          English
          arrow-up
          12
          ·
          11 days ago

          the rust devs wanted to CREATE official structure definitions that don’t exist in C so that there was more semantic meaning to the APIs