You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Background: In Linux kernel, we have Linux Kernel Memory (Consistency) Model, or LKMM for short, which provides a set of atomic primitives and a (somewhat) formal model to describe their semantics. And there are couples of differences between LKMM and Rust's memory model. So when Rust comes into the picture of Linux kernel development, one thing we need to deal with is which memory model to use.
I'd like to propose that we have a place where we can document/track our current "policy" and any future plan for memory ordering models (including synchronization primitives and program-preserved ordering) used in Rust-for-Linux. Eventually, we will have in-kernel documentation for this, but let's use this issue to get things clarified in early stages.
I had a fewdiscussions. And based on the discussions, below is the best option to start with in my opinion:
Avoid using Rust atomics and memory ordering model (i.e. C11 memory ordering model).
Implement barriers and LKMM atomics via asm! or FFI, and in-kernel Rust code should use LKMM atomics and the model.
Couples of reasons here (I will provide some summary about the previous discussion in this issue in the form of comments as well):
Dealing with two memory ordering models could introduce risks in both practice and theory, and most of people working on Linux kernel are already (or should be) familiar with Linux Kernel Memory Model.
It's very likely a Rust driver would need to talk with a C component, having (and using) a Rust version of LKMM atomics is necessary in this case to avoid reasoning with two models.
It's simple to just have one memory model to start with, and we can always re-evaluate as things move on.
I'm going to prepare a patchset to add initial documentation of the memory model policy and implementation of atomic APIs. Happy to hear any feedback, and tests and reviews in the future are welcome!
The text was updated successfully, but these errors were encountered:
Background: In Linux kernel, we have Linux Kernel Memory (Consistency) Model, or LKMM for short, which provides a set of atomic primitives and a (somewhat) formal model to describe their semantics. And there are couples of differences between LKMM and Rust's memory model. So when Rust comes into the picture of Linux kernel development, one thing we need to deal with is which memory model to use.
I'd like to propose that we have a place where we can document/track our current "policy" and any future plan for memory ordering models (including synchronization primitives and program-preserved ordering) used in Rust-for-Linux. Eventually, we will have in-kernel documentation for this, but let's use this issue to get things clarified in early stages.
I had a few discussions. And based on the discussions, below is the best option to start with in my opinion:
asm!
or FFI, and in-kernel Rust code should use LKMM atomics and the model.Couples of reasons here (I will provide some summary about the previous discussion in this issue in the form of comments as well):
I'm going to prepare a patchset to add initial documentation of the memory model policy and implementation of atomic APIs. Happy to hear any feedback, and tests and reviews in the future are welcome!
The text was updated successfully, but these errors were encountered: