Comment by julienfr112
1 day ago
I'm the average rust fanboy, but DMA is something I would rather do in C, as there would probably be more line of unsafe rust code than safe...
1 day ago
I'm the average rust fanboy, but DMA is something I would rather do in C, as there would probably be more line of unsafe rust code than safe...
Even unsafe rust is safer than C. Error management, type safety, modern language, etc. There are many reasons to use Rust in place of C, even if your whole code is one giant unsafe blob.
I run eBPF code written in Rust in production, and oh boy how more readable it is compared to C. Even simple stuff like `if let Some`, actual sum types, generics, are enough to warrant using Rust over C. And its endtrypoint is basically unsafe { ... }.
Don't mislead people like this. If you are writing C, oh well. If you are writing big unsafe Rust blocks, genuinely, you are holding it wrong. Rust's strength is that unsafe blocks are minimal and well-isolated, giving both the flexibility and performance of C and the assurances of safe Rust. The default is safe Rust and unsafe authors must ensure their code works when it is eventually contacted by safe Rust. That's why we can say Rust is memory-safe, like Java or C#, even though unsafe is a clearly advertised feature. Unsafe Rust is, at best, on par with C. Nice language features do not fix UB. If you're not taking advantage of safe Rust, you lose the benefits of using unsafe Rust. Rust's main innovation is the borrow checker; use it!
In the specific case where I'm using Rust, unsafe is definitely better. I mostly write eBPF XDP programs for where I write unsafe code.
So yes I agree that I don't get safety benefits. However, it does not mean I don't get increased reliability from it. Just type safety allows APIs to be expressed in ways you cannot hold them wrong. Heck, just getting a Result<u32, u32> instead of a i64 for faillible operations is a godsend.
In the end, this is why I'm a big proponent of Rust for many areas of programming, including areas where memory safety is the least of your concerns. My gRPC APIs are written in Rust, my system daemons are written in Rust, my eBPF probes are written in Rust. Rust is a modern language whose design is deliberate on many levels to address common issues in programming. If you'd ask me, Rust's "marketing" putting memory safety first is quite a disservice as there are many areas where it helps writing correct programs.
Greg KH noted this in his email in another branch of the thread, and I wholeheartedly agree with him.
3 replies →
Arguably unsafe Rust is a bit less safe than C. But fortunately you need much less of it (even in something like a DMA subsystem there's going to be plenty of safe code).
https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/
eBPF is such a supertool that is slept on. I have been working on turning my nftables into it, (on low-latency/high-throughput targets) may I ask how you are using it with Rust?
Sure! I use the aya framework (https://aya-rs.dev) that provides the kernel-side bindings to write the probes in Rust, and the userspace tooling to load it in the kernel, interacts with maps, etc. Quite a joy to work with, and has all the niceties you'd expect from using Rust.
We write XDP apps for custom dataplanes where traditionally DPDK would be used (routers and such). Our upcoming network acls are written this way, so close to your netfilter usage.
3 replies →
> Even unsafe rust is safer than C.
Even Zig is safer than unsafe Rust.
I think the "drama" is that the DMA guys want to write C, only.
However they have opinions about how people are interfacing with their code for DMA from Rust, and the rust developers are maybe bent out of shape about it.
Linus is saying: If you're not doing it, then you don't get to have opinions.
> Linus is saying: If you're not doing it, then you don't get to have opinions.
But eventually he would have to, if those rust interfaces becomes part of kernel. The entire drama is about DMA guys not wanting to deal with this in future.
They're trying to do DMA in C, by calling the existing DMA code that's written in C from new drivers written in Rust. Their attempt to make an interface from Rust to the existing DMA code is what's being rejected by the guy maintaining the existing DMA code.
I disagree. The Rust code has an abstraction for DMA’d objects that gives them a safe interface.