New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shared references of mutable static warnings #3841
Comments
We definitely need to do something about these (otherwise we cannot update nightly). We would like to keep track of where these warnings are happening and see if we can fix the underlying issue. I wonder if we should create our own macro which wraps |
One workaround are diffs that look like: diff --git a/kernel/src/deferred_call.rs b/kernel/src/deferred_call.rs
index cdac8330d..e21137ab8 100644
--- a/kernel/src/deferred_call.rs
+++ b/kernel/src/deferred_call.rs
@@ -142,7 +142,7 @@ impl DeferredCall {
pub fn new() -> Self {
// SAFETY: No accesses to CTR are via an &mut, and the Tock kernel is
// single-threaded so all accesses will occur from this thread.
- let ctr = unsafe { &CTR };
+ let ctr = unsafe { core::ptr::addr_of!(CTR).as_ref().unwrap() };
let idx = ctr.get() + 1;
ctr.set(idx);
DeferredCall { idx } which seems, undesirable. |
@bradjc I do, unfortunately, think that your posted diff is more or less the way to go here. We're not going to be able to rid ourselves of all usages of mutable statics, in particular in code paths like We can think about introducing a special type of Cell for this purpose, not unlike I'm thinking of an interface that has a safe constructor, but unsafe accessors (getters and setters). This because, to store this This should have identical semantics to what we're doing now, but is avoiding unwieldy syntax, and prevents accidentally "leaking" a Rust reference to a mutable static for longer than we'd want to have it in scope, and thus would be potentially in danger of violating Rust's aliasing constraints. @kupiakos Interested to hear your thoughts on this as well. |
Plan is to look into some sort of *Cell approach, or something principled. However, if there is not a solution in place by April 1, 2024, we'll move forward with the |
Don't use diff --git a/kernel/src/deferred_call.rs b/kernel/src/deferred_call.rs
index cdac8330d..e21137ab8 100644
--- a/kernel/src/deferred_call.rs
+++ b/kernel/src/deferred_call.rs
@@ -142,7 +142,7 @@ impl DeferredCall {
pub fn new() -> Self {
// SAFETY: No accesses to CTR are via an &mut, and the Tock kernel is
// single-threaded so all accesses will occur from this thread.
- let ctr = unsafe { &CTR };
+ let ctr = unsafe { &*core::ptr::addr_of!(CTR) };
let idx = ctr.get() + 1;
ctr.set(idx);
DeferredCall { idx } I think the best balance here would be a newtype implementing |
Great, that's exactly what I've been prototyping. Can share on a future call, will unfortunately miss the next two. Might hand off to @alevy to share instead. |
While compiling tock with the latest nightly version of rust,
nightly-2024-02-08
, I encounter 25 warnings regarding the usage of shared references of mutable static in folders such asarch/
,kernel/
,chips/
andboards/
as it can be seen bellow:If I understand correctly, for the moment this is just a warning, but it will soon become a compile error. We will need some workarounds for this.
Todo
PROCESSES
,CHIP
, etc. in boards.The text was updated successfully, but these errors were encountered: