Comment by throw_a_grenade
3 hours ago
Also you can't do self-referential strutcs.
Double-linked lists are also pain to implement, and they're are heavily used in kernel.
3 hours ago
Also you can't do self-referential strutcs.
Double-linked lists are also pain to implement, and they're are heavily used in kernel.
> Also you can't do self-referential strutcs.
You mean in safe rust? You can definitely do self-referential structs with unsafe and Pin to make a safe API. Heck every future generated by the compiler relies on this.
There's going to be ~zero benefit of Rust safety mechanisms in the kernel, which I anticipate will be littered with the unsafe sections. I personally see this move not as much technical as I see it as a political lobbying one (US gov). IMHO for Linux kernel development this is not a good news since it will inevitably introduce friction in development and consequently reduce the velocity, and most likely steer away certain amount of long-time kernel developers too.
Don’t spread FUD, you can check some example code yourself.
https://git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/l...
Sorry but what have I said wrong? The nature of code written in kernel development is such that using unsafe is inevitable. Low-level code with memory juggling and patterns that you usually don't find in application code.
And yes, I have had a look into the examples - maybe one or two years there was a significant patch submitted to the kernel and number of unsafe sections made me realize at that moment that Rust, in terms of kernel development, might not be what it is advertised for.
> https://git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/l..
Right? Thank you for the example. Let's first start by saying the obvious - this is not an upstream driver but a fork and it is also considered by its author to be a PoC at best. You can see this acknowledged by its very web page, https://rust-for-linux.com/nvme-driver, by saying "The driver is not currently suitable for general use.". So, I am not sure what point did you try to make by giving something that is not even a production quality code?
Now let's move to the analysis of the code. The whole code, without crates, counts only 1500 LoC (?). Quite small but ok. Let's see the unsafe sections:
rnvme.rs - 8x unsafe sections, 1x SyncUnsafeCell used for NvmeRequest::cmd (why?)
nvme_mq/nvme_prp.rs - 1x unsafe section
nvme_queue.rs - 6x unsafe not sections but complete traits
nvme_mq.rs - 5x unsafe sections, 2x SyncUnsafeCell used, one for IoQueueOperations::cmd second for AdminQueueOperations::cmd
In total, this is 23x unsafe sections/traits over 1500LoC, for a driver that is not even a production quality driver. I don't have time but I wonder how large this number would become if all crates this driver is using were pulled in into the analysis too.
Sorry, I am not buying that argument.
2 replies →