• dinckel@lemmy.world
    link
    fedilink
    arrow-up
    8
    ·
    15 hours ago

    I find this headline incredibly misleading. Proper non-trivial Rust drivers already exist in the kernel. The entire Apple graphical stack for the ARM M-series SoCs is written in Rust, and it’s beyond excellent

    • ethancedwards8@programming.dev
      link
      fedilink
      English
      arrow-up
      4
      ·
      11 hours ago

      I’m not sure it’s mainline yet? It may just be part of the Asahi project. From my understanding, they are being developed out of tree and will be merged/submitted later.

      • NudeNewt@lemm.ee
        link
        fedilink
        English
        arrow-up
        2
        ·
        10 hours ago

        Yeah a lot of it is in the unstable builds for practically any mainstream distros.

    • Dave.@aussie.zone
      link
      fedilink
      arrow-up
      24
      arrow-down
      2
      ·
      2 days ago

      Anything useful is still “unsafe.”

      So you take care with the bits that have to deal with C, just like you have to with C code itself, and then all the rest of your code is still safe by default. Still a net improvement, yes?

      • deaf_fish@lemm.ee
        link
        fedilink
        arrow-up
        2
        arrow-down
        4
        ·
        edit-2
        1 day ago

        Yes, then they shouldn’t say it is “safe” because it isn’t. They should say “more safe”, or be more specific.

      • bluGill@fedia.io
        link
        fedilink
        arrow-up
        3
        arrow-down
        5
        ·
        2 days ago

        In a driver what else is there? Either you deal with c or hardware.

        • thews@lemmy.world
          link
          fedilink
          arrow-up
          10
          ·
          1 day ago

          In a driver, there’s a lot more than just C and hardware interaction. You also have to deal with:

          Concurrency and Synchronization – Managing locks, spinlocks, atomic operations, and ensuring safe access to shared resources.

          Memory Management – Allocating kernel memory safely, handling DMA buffers, and avoiding memory leaks or invalid accesses.

          Interrupt Handling – Dealing with IRQs, deferring work using tasklets, workqueues, or bottom halves.

          State Management – Handling suspend, resume, and power states efficiently.

          Error Handling and Recovery – Ensuring robustness in the presence of hardware failures or unexpected states.

          Device Trees and ACPI – Parsing platform configuration data.

          Firmware Communication – Loading and interfacing with device firmware blobs.

          Kernel APIs and Subsystems – Interacting with networking, block devices, input devices, and other kernel frameworks.

          Performance Optimizations – Managing cache coherency, NUMA awareness, and latency-sensitive operations.

          Security Considerations – Preventing privilege escalation, ensuring safe user-space interaction, and sandboxing where applicable.

          Yes, interfacing with hardware often requires unsafe Rust or C, but a lot of driver logic isn’t directly interacting with raw hardware registers. Rust can help improve safety in many of these areas by reducing common C pitfalls like use-after-free, null dereferences, and buffer overflows.