7 ms·

Also you can't do self-referential strutcs. Double-linked lists are also pain to implement, and they're are heavily used in kernel.

menaerus 10mo ago
[flagged]
- baq 10mo ago
  Don’t spread FUD, you can check some example code yourself. https://git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/linux.git/tree/drivers/block/rnvme?h=rnvme&id=1db5efbbda1d3cc16f1ac4808b7ef384aac417e8 https://git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/l...
  - menaerus 10mo ago
    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 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 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.
    - baq 10mo ago
      > I am not sure what point did you try to make by giving something that is not even a production quality code? let's start by prefacing that 'production quality' C is 100% unsafe in Rust terms. > Sorry, I am not buying that argument. here's where we fundamentally disagree: you listed a couple dozen unsafe places in 1.5kLOC of code; let's be generous and say that's 10% - and you're trying to sell it as a bad thing, whereas I'm seeing the same numbers and think it's a great improvement over status quo ante.
      - menaerus 10mo ago
        > let's start by prefacing that 'production quality' C is 100% unsafe in Rust terms. I don't know what one should even make from that statement. > here's where we fundamentally disagree: you listed a couple dozen unsafe places in 1.5kLOC of code; let's be generous and say that's 10% It's more than 10%, you didn't even bother to look at the code but still presented it, what in reality is a toy driver example, as something credible (?) to support your argument of me spreading FUD. Kinda silly. Even if it was only that much (10%), the fact it is in the most crucial part of the code makes the argument around Rust safety moot. I am sure you heard of 90/10 rule. The time will tell but I am not holding my breath. I think this is a bad thing for Linux kernel development.
        baq 10mo ago
        > I don't know what one should even make from that statement. it's just a fact. by definition of the Rust language unsafe Rust is approximately as safe as C (technically Rust is still safer than C in its unsafe blocks, but we can ignore that.) > you didn't even bother to look at the code but still presented of course I did, what I've seen were one-liner trait impls (the 'whole traits' from your own post) and sub-line expressions of unsafe access to bindings.
        zozbot234 10mo ago
        > technically Rust is still safer than C in its unsafe blocks This is quite dubious in a practical sense, since Rust unsafe blocks must manually uphold the safety invariants that idiomatic Safe Rust relies on at all times, which includes, e.g. references pointing to valid and properly aligned data, as well as requirements on mutable references comparable to what the `restrict` qualifier (which is rarely used) involves in C. In practice, this is hard to do consistently, and may trigger unexpected UB. Some of these safety invariants can be relaxed in simple ways (e.g. &Cell<T> being aliasable where &mut T isn't) but this isn't always idiomatic or free of boilerplate in Safe Rust.
  - qwm 10mo ago
    > Don’t spread FUD Only in cryptocurrency and Rust do I see this kind of phrasing used.
- deleted 10mo ago
  [deleted]
K0nserv 10mo ago
> 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.

menaerus 10mo ago

[flagged]

baq 10mo ago
Don’t spread FUD, you can check some example code yourself. https://git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/linux.git/tree/drivers/block/rnvme?h=rnvme&id=1db5efbbda1d3cc16f1ac4808b7ef384aac417e8 https://git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/l...
- menaerus 10mo ago
  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 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 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.
  - baq 10mo ago
    > I am not sure what point did you try to make by giving something that is not even a production quality code? let's start by prefacing that 'production quality' C is 100% unsafe in Rust terms. > Sorry, I am not buying that argument. here's where we fundamentally disagree: you listed a couple dozen unsafe places in 1.5kLOC of code; let's be generous and say that's 10% - and you're trying to sell it as a bad thing, whereas I'm seeing the same numbers and think it's a great improvement over status quo ante.
    - menaerus 10mo ago
      > let's start by prefacing that 'production quality' C is 100% unsafe in Rust terms. I don't know what one should even make from that statement. > here's where we fundamentally disagree: you listed a couple dozen unsafe places in 1.5kLOC of code; let's be generous and say that's 10% It's more than 10%, you didn't even bother to look at the code but still presented it, what in reality is a toy driver example, as something credible (?) to support your argument of me spreading FUD. Kinda silly. Even if it was only that much (10%), the fact it is in the most crucial part of the code makes the argument around Rust safety moot. I am sure you heard of 90/10 rule. The time will tell but I am not holding my breath. I think this is a bad thing for Linux kernel development.
      - baq 10mo ago
        > I don't know what one should even make from that statement. it's just a fact. by definition of the Rust language unsafe Rust is approximately as safe as C (technically Rust is still safer than C in its unsafe blocks, but we can ignore that.) > you didn't even bother to look at the code but still presented of course I did, what I've seen were one-liner trait impls (the 'whole traits' from your own post) and sub-line expressions of unsafe access to bindings.
        zozbot234 10mo ago
        > technically Rust is still safer than C in its unsafe blocks This is quite dubious in a practical sense, since Rust unsafe blocks must manually uphold the safety invariants that idiomatic Safe Rust relies on at all times, which includes, e.g. references pointing to valid and properly aligned data, as well as requirements on mutable references comparable to what the `restrict` qualifier (which is rarely used) involves in C. In practice, this is hard to do consistently, and may trigger unexpected UB. Some of these safety invariants can be relaxed in simple ways (e.g. &Cell<T> being aliasable where &mut T isn't) but this isn't always idiomatic or free of boilerplate in Safe Rust.
- qwm 10mo ago
  > Don’t spread FUD Only in cryptocurrency and Rust do I see this kind of phrasing used.
deleted 10mo ago
[deleted]

K0nserv 10mo ago

> 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.