Originally posted by Sonadow
View Post
Announcement
Collapse
No announcement yet.
The Work-In-Progress Rust-Written Apple DRM Driver Manages To Start Wayland's Weston
Collapse
X
-
Last edited by Developer12; 30 September 2022, 10:18 AM.
-
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.
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.
- Likes 1
Comment
-
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.
- Likes 1
Comment
-
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.
Comment
-
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.
Comment
-
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.
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
Comment