Announcement

Collapse
No announcement yet.

The Work-In-Progress Rust-Written Apple DRM Driver Manages To Start Wayland's Weston

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by Sonadow View Post
    I'm more interested in what she's using for her Vtuber setupand whether it's available on Linux.

    Otherwise I'll just go with the path of least resistance and do my Vtuber debut on Windows where all the pieces are already available.
    Inochi2D https://twitter.com/LinaAsahi/status...61381584699392
    Last edited by Developer12; 30 September 2022, 10:18 AM.

    Comment


    • #22
      Originally posted by Developer12 View Post

      That may be superseded by the NVMe rust driver.
      I think the NVMe driver is a proof of concept, not intended to replace the already existing NVMe driver. I could be wrong though.

      Comment


      • #23
        Originally posted by jacob View Post

        I think the NVMe driver is a proof of concept, not intended to replace the already existing NVMe driver. I could be wrong though.
        It's definitely fast enough to be a replacement. It's within a few percent without any optimization, and if the maintenance burden is lower then it's a prime candidate.
        Linux traditionally doesn't tend to keep two drivers around for the same device, but Rust may be an exception to the rule until GCC support comes together or the old LLVM-unsupported architectures are dropped.

        Comment


        • #24
          Originally posted by Developer12 View Post

          It's definitely fast enough to be a replacement. It's within a few percent without any optimization, and if the maintenance burden is lower then it's a prime candidate.
          Linux traditionally doesn't tend to keep two drivers around for the same device, but Rust may be an exception to the rule until GCC support comes together or the old LLVM-unsupported architectures are dropped.
          That's the key part. NVMe is so fundamental that its driver needs to build and work reliably on all supported architectures. The M1 GPU driver on the other hand only needs to work on aarch64.

          Comment


          • #25
            Originally posted by jacob View Post

            That's the key part. NVMe is so fundamental that its driver needs to build and work reliably on all supported architectures. The M1 GPU driver on the other hand only needs to work on aarch64.
            How many synopsys ARC CPUs are being used with NVMe? MIPS? Hexagon? SPARC? For any architectures that have a PCIe bus, there's rust support.

            Comment


            • #26
              Originally posted by Developer12 View Post

              How many synopsys ARC CPUs are being used with NVMe? MIPS? Hexagon? SPARC? For any architectures that have a PCIe bus, there's rust support.
              We are talking about the kernel here, so basically only officially supported, tier-1 compiler is acceptable. Not all archs with a PCIe bus have that level of rust support, for example loongarch64 doesn't.

              Comment


              • #27
                Originally posted by jacob View Post

                We are talking about the kernel here, so basically only officially supported, tier-1 compiler is acceptable. Not all archs with a PCIe bus have that level of rust support, for example loongarch64 doesn't.
                Loonarch arguably isn't even truly supported in linux. A year ago I was reading about their patches being rejected yet again for being too similar to mips. It's not surprising that there's no rust support for them yet. A more interesting question is "when will new architectures be rejected from upstreaming due to missing rust support?" After all, GCC support is a hard requirement, and was required of longarch.

                It's also already been established that not having compiler support for every architecture supported by linux is NOT a prerequisite for rust drivers landing. You can land a rust driver for anything you want. The only restriction is that it can't be non-optional core kernel code. Note that there's nothing in that contract that says your device can't simply not work on non rust platforms. It would be a dick move to take NVMe support away from whoever the hell can use it without a PCIe slot, but if I'm implementing support for a new serial port driven toaster, I'm within my rights to implement only a rust driver and simply leave the device unavailable to anyone running pure C.

                Note my key points:

                (1) It's perfectly reasonable for rust drivers to enjoy the following exception: there could be a C and a rust driver in-tree, with the rust driver being preferable and selected on architectures where available. (it's not normally the case to have two in-tree drivers for the same device)

                (2) For the NVMe driver specifically, I don't think you can name an architecture supported by linux that has PCIe ports to which an NVMe drive could be attached, and yet doesn't have rust support, brand-new mips clone notwithstanding (see above). Thus, the NVMe driver requiring rust is, in practice, a near non-issue. All established architectures for which devices are being made and supported have rust, even esoteric ones like s390 from IBM.

                Comment

                Working...
                X