lkml.org 
[lkml]   [2021]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 00/13] [RFC] Rust support
Date
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.

\
 
 \ /
  Last update: 2021-04-19 20:39    [W:0.339 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site