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...
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 { ... }.
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.
I do worry about running so much stuff in kernel space though. Imagine a widespread 0day that hits the kernel, or kernel panics causing kernel crashes that require reboots, the user space priv escalation, etc...
Are you doing fail-open or fail-closed? I've been on the fence on that.
- a cloud provider writing a dataplane using ebpf does not have to provide the source - a company selling on-prem software (e.g. esxi) that ships with ebpf probes would need to distribute their source
(note: IANAL)
https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/
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.
Generally, people talk about type system benefits and whatnot on top of safe languages. If you can't ensure safety, UB occurs and that goes out the window. I can't tell how you use unsafe in absolute terms, so I will just hope that you are saying you have an unusually high proportion of unsafe code but still manageable. Otherwise it invites the same "look over everything to make sure nothing can go wrong" practice as with C.
> 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.
Memory safety should never be "the least of your concerns". The movement around memory-safe languages is because memory safety is the bedrock on which orthogonal concerns must be placed. Unsafe Rust is well and good because it is (hopefully) used sparingly and with great caution. It is the typical absence of unsafe Rust that characterizes its strengths. I agree that Rust has decent, if not strong, qualities for many other programming sectors, and many Rust critics do make an unreasonable amount of noise about memory safety and unsafe Rust, but Rust is what it is first and foremost because of its approach to memory safety, and everyone can agree to that. Your first comment undermines your stated desire to communicate that Rust should be seen as offering "memory safety plus more goodies".
>> 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.
only make sense in the context of eBPF or similar verification environments. That was made more clear in their second comment, so I'm really sorry about that.
>> 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.
To my understanding, it is only eBPF out of these that has this particular "write all the unsafe you want" quality. Overall, we were on the same page about Rust's guarantees and features this whole time, but I do think @tuetuopay's messaging/"marketing" was pretty confusing, and doesn't help with Rust's marketing that they pointed out.
Even Zig is safer than unsafe Rust.
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.
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.