Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Driver code has a lot of concurrency and is very unforgiving for any mishandling of memory. If you want to write good kernel code in C you need to have a strong mental model of who owns what, who does what on whom, what can interrupt, what can be interrupted, what shouldn't be interrupted etc...

Having the compiler enforce some of these invariants for you might well end up making writing the code easier, not harder. Rust has a steep learning curve, that's absolutely true, but in my experience I feel a lot more at ease writing complicated parallel code with complicated ownership models in Rust than in C.

C is a trickster: in practice if you want to write correct C code you have to use a memory model very similar to that of Rust, the main difference being that Rust forces you to do it (mostly) right whereas C will gladly let you write completely broken code.



Does Rust handle anything with memory barriers? I can handle concurrency, interrupt handlers, etc, but memory barriers always trouble me.


It will force your code to be memory safe, but it can't enforce that you have the correct semantics.

https://doc.rust-lang.org/std/sync/atomic/fn.fence.html exists, but Rust can't force you to say, use the correct ordering.


Right, so no different than C in this regard.


Really, you should rarely be using raw memory barriers even in C, IMO. The C11/C++11 atomics model (which Rust also uses) is substantially nicer. Though, unfortunately, still extremely tricky to get right.


The only time that I ever had to worry about that was when writing drivers for the Linux kernel.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: