Messages in this thread | | | Date | Sat, 23 Oct 2021 12:07:10 +0200 | From | Damian Tometzki <> | Subject | Re: "Using Rust for kernel development": Memory model |
| |
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.
| |