On Fri, Mar 22, 2024 at 04:38:35PM -0700, Boqun Feng wrote: > Hi, > > Since I see more and more Rust code is comming in, I feel like this > should be sent sooner rather than later, so here is a WIP to open the > discussion and get feedback. > > One of the most important questions we need to answer is: which > memory (ordering) model we should use when developing Rust in Linux > kernel, given Rust has its own memory ordering model[1]. I had some > discussion with Rust language community to understand their position > on this: > > https://github.com/rust-lang/unsafe-code-guidelines/issues/348#issuecomment-1218407557 > https://github.com/rust-lang/unsafe-code-guidelines/issues/476#issue-2001382992 > > My takeaway from these discussions, along with other offline discussion > is that supporting two memory models is challenging for both correctness > reasoning (some one needs to provide a model) and implementation (one > model needs to be aware of the other model). So that's not wise to do > (at least at the beginning). So the most reasonable option to me is: > > we only use LKMM for Rust code in kernel (i.e. avoid using > Rust's own atomic). > > Because kernel developers are more familiar with LKMM and when Rust code > interacts with C code, it has to use the model that C code uses. I wonder about that. The disadvantage of only supporting LKMM atomics is that we'll be incompatible with third party code, and we don't want to be rolling all of our own data structures forever. Do we see a path towards eventually supporting the standard Rust model? Perhaps LKMM atomics could be reworked to be a layer on top of C/C++ atomics. When I last looked, they didn't look completely incompatible; rather, there is a common subset that both support with the same semantics, and either has some things that it supports and the other doesn't (i.e., LKMLL atomics have smp_mb__after_atomic(); this is just a straightforward optimization to avoid an unnecessary barrier on architectures where the atomic already provided it).
