Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sat, 23 Oct 2021 12:07:10 +0200
From:   Damian Tometzki <dtometzki@fedoraproject.org>
To:     "Paul E. McKenney" <paulmck@kernel.org>
Cc:     gregkh@linuxfoundation.org, tglx@linutronix.de, clm@fb.com,
        corbet@lwn.net, peterz@infradead.org, mingo@redhat.com,
        will@kernel.org, longman@redhat.com,
        miguel.ojeda.sandonis@gmail.com, wedsonaf@google.com,
        boqun.feng@gmail.com, rust-for-linux@vger.kernel.org,
        linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: "Using Rust for kernel development": Memory model
Message-ID: <YXPezv907nRp62OD@fedora.tometzki.de>
Reply-To: Damian Tometzki <linux@tometzki.de>
Mail-Followup-To: "Paul E. McKenney" <paulmck@kernel.org>,
        gregkh@linuxfoundation.org, tglx@linutronix.de, clm@fb.com,
        corbet@lwn.net, peterz@infradead.org, mingo@redhat.com,
        will@kernel.org, longman@redhat.com,
        miguel.ojeda.sandonis@gmail.com, wedsonaf@google.com,
        boqun.feng@gmail.com, rust-for-linux@vger.kernel.org,
        linux-kernel@vger.kernel.org, kernel-team@fb.com
References: <20211022210315.GA2582977@paulmck-ThinkPad-P17-Gen-1>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20211022210315.GA2582977@paulmck-ThinkPad-P17-Gen-1>
User-Agent: Mutt
Organization: Linux hacker
Precedence: bulk

Hello Paul,

many thanks for the great article and your time. 

Damian

On Fri, 22. Oct 14:03, Paul E. McKenney wrote:
> Hello!
> 
> This email is in response to the Rust memory-model discussion at
> Maintainers Summit (https://lwn.net/Articles/870555/).
> 
> My blog series entitled "So You Want to Rust the Linux Kernel?" [1] is now
> feature complete, and a big "thank you" for all the great feedback that
> this series received.  I have recommendations at "TL;DR: Memory-Model
> Recommendations for Rusting the Linux Kernel" [2], and this email is
> therefore TL;DR(TL;DR).
> 
> Given the Rust-for-Linux's focus on device drivers, the Linux-kernel
> features requiring special Linux-kernel-memory-model features can be
> avoided within Rust code.  For example, code using RCU, sequence locking,
> or control dependencies can remain written in C, and higher-level APIs
> based on that code can be exported to Rust in manner consistent with
> Rust's current ownership models.
> 
> This approach reasonably straightforwardly accommodates the more likely
> short-term choices for the Rust memory model, which would presumably be
> the C/C++ memory model or some stronger subset thereof, for example, one
> that excludes consume and relaxed accesses.  If the Rust community chooses
> a less mainstream memory model, the code that makes C-code functionality
> available to Rust code would need to take up any slack.  For example,
> memory barriers might need to be inserted into this wrapper code.
> 
> Longer term, I hope that the core Rust community will become interested
> in supporting modern techniques, and to that end I have suggested some
> longer-term goals in the TL;DR post.
> 
> There is already plenty of interest in modern techniques within the
> greater Rust community, and number of people produced prototype wrappers
> for various sequence-locking and RCU use cases.  I am grateful to all
> who took on this challenge.
> 
> However, arriving at good wrappers requires a sufficient understanding
> of Rust to be combined with sufficient knowledge of the Linux kernel's
> wide variety of sequence-locking and RCU use cases, and unfortunately
> this combining seems to be some ways off [3].  It therefore makes sense to
> defer the need for such wrappers in order to allow time for this diffusion
> of knowledge to take place.  So, in the near term, if a Rust-code project
> were to request direct access to RCU APIs, I would instead ask them to
> create higher-level APIs so that the RCU APIs would remain within C code.
> I am also working to better document the wide range of RCU use cases
> that are present in the Linux kernel, which I hope will speed up the
> process of working out what a Rust-language RCU API should look like.
> 
> Of course, the corresponding choices for sequence locking are in the
> capable hands of the relevant maintainers, who are CCed.
> 
> Thoughts?
> 
> 						Thanx, Paul
> 
> [1] https://paulmck.livejournal.com/62436.html
> 
> [2] https://paulmck.livejournal.com/65341.html
> 
> [3] This process took four years in the C/C++ standards committees,
>     but perhaps things will go faster with the Rust community.