* "Using Rust for kernel development": Memory model
@ 2021-10-22 21:03 Paul E. McKenney
2021-10-23 10:07 ` Damian Tometzki
0 siblings, 1 reply; 2+ messages in thread
From: Paul E. McKenney @ 2021-10-22 21:03 UTC (permalink / raw)
To: gregkh, tglx, clm, corbet
Cc: peterz, mingo, will, longman, miguel.ojeda.sandonis, wedsonaf,
boqun.feng, rust-for-linux, linux-kernel, kernel-team
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: "Using Rust for kernel development": Memory model
2021-10-22 21:03 "Using Rust for kernel development": Memory model Paul E. McKenney
@ 2021-10-23 10:07 ` Damian Tometzki
0 siblings, 0 replies; 2+ messages in thread
From: Damian Tometzki @ 2021-10-23 10:07 UTC (permalink / raw)
To: Paul E. McKenney
Cc: gregkh, tglx, clm, corbet, peterz, mingo, will, longman,
miguel.ojeda.sandonis, wedsonaf, boqun.feng, rust-for-linux,
linux-kernel, kernel-team
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2021-10-23 10:07 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-22 21:03 "Using Rust for kernel development": Memory model Paul E. McKenney
2021-10-23 10:07 ` Damian Tometzki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).