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

  • Developer12
    replied
    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.

    Leave a comment:


  • jacob
    replied
    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.

    Leave a comment:


  • Developer12
    replied
    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.

    Leave a comment:


  • jacob
    replied
    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.

    Leave a comment:


  • Developer12
    replied
    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.

    Leave a comment:


  • jacob
    replied
    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.

    Leave a comment:


  • Developer12
    replied
    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.

    Leave a comment:


  • Developer12
    replied
    Originally posted by jacob View Post
    So this will be the first production driver written in Rust.
    That may be superseded by the NVMe rust driver.

    Leave a comment:


  • Developer12
    replied
    Originally posted by MastaG View Post
    It's nice to see it progressing so fast.
    Kinda unfair that Apple doesn't contribute a single bit to this though, but in the end, their users will benefit with the possibility of switching to Linux.
    I wonder who's funding all this and for which purpose...
    It's funded mostly via patreon.
    Last edited by Developer12; 30 September 2022, 12:10 AM.

    Leave a comment:


  • qarium
    replied
    Originally posted by GeneralZod View Post
    man thats golden awesome super ultra good.
    Hector Martin really beats the shit out of these haters.

    Leave a comment:

Working...
X