Messages in this thread | | | From | Paolo Bonzini <> | Subject | Re: [PATCH 00/13] [RFC] Rust support | Date | Mon, 19 Apr 2021 20:38:35 +0200 |
| |
On 19/04/21 19:14, Linus Torvalds wrote: > On Mon, Apr 19, 2021 at 2:36 AM Peter Zijlstra <peterz@infradead.org> wrote: >> >> I also don't see how this is better than seq_cst. >> >> But yes, not broken, but also very much not optimal. > > I continue to feel like kernel people should just entirely ignore the > C++ memory ordering standard. > > It's inferior to what we already have, and simply not helpful. It > doesn't actually solve any problems as far as the kernel is concerned, > and it generates its own set of issues (ie assuming that the compiler > supports it, and assuming the compiler gets it right). > > The really subtle cases that it could have been helpful for (eg RCU, > or the load-store control dependencies) were _too_ subtle for the > standard. > > And I do not believe Rust changes _any_ of that.
It changes it for the worse, in that access to fields that are shared across threads *must* either use atomic types (which boil down to the same compiler intrinsics as the C/C++ memory model) or synchronization primitives. LKMM operates in the grey area between the C standard and what gcc/clang actually implement, but there's no such grey area in Rust unless somebody wants to rewrite arch/*/asm atomic access primitives and memory barriers in Rust.
Of course it's possible to say Rust code just uses the C/C++/Rust model and C code follows the LKMM, but that really only delays the inevitable until a driver is written part in C part in Rust, and needs to perform accesses outside synchronization primitives.
Paolo
> Any kernel Rust code will simply have to follow the LKMM rules, and > use the kernel model for the interfaces. Things like the C++ memory > model is simply not _relevant_ to the kernel.
| |