[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20211022041051.GA234258@paulmck-ThinkPad-P17-Gen-1>
Date: Thu, 21 Oct 2021 21:10:51 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: peterz@...radead.org, mingo@...hat.com, will@...nel.org,
longman@...hat.com, boqun.feng@...il.com
Cc: linux-kernel@...r.kernel.org
Subject: FYI, RCU, sequence locks, and Rust
Hello!
On the off-chance that this is useful for you guys for sequence locking,
here is the stance I intend to take for Rust wrappers for RCU APIs:
1. My first reaction to submission of Rust wrappers for the RCU
API will be to ask hard questions about the possibility of
higher-level APIs.
2. If higher-level APIs are infeasible, I will look carefully at
which RCU use cases are supported by the proposed wrappering. I
am working to improve documentation of the range of RCU use cases
in order to help submitters to do this as well. (This work will
likely be helpful elsewhere as well.)
3. Again, if higher-level APIs are infeasible, I will look carefully
at how the Rust wrappers are helping to find bugs. This will
clearly require me to continue learning Rust, as this requires
me to have a detailed view of Rust's ownership mechanisms and how
things like reference-counting use cases work around limitations
in these mechanisms.
This procedure should help buy the time required for me to learn more
about the Rust language and for the Rust community to learn more about
RCU and its many use cases.
Your sequence-locking mileage may vary, but one thing that sequence
locking has in common with RCU is read-side critical sections that are
a bit different than Rust seems to expect.
More information here:
https://paulmck.livejournal.com/62436.html
"So You Want to Rust the Linux Kernel?"
And more specifically, here:
https://paulmck.livejournal.com/65341.html
"TL;DR: Memory-Model Recommendations for Rusting the Linux Kernel"
Again, on the off-chance that this is helpful.
Thanx, Paul
Powered by blists - more mailing lists