Optional unprivileged even-more-unsafe mode for certain use cases?
cbiffle opened this issue · 3 comments
Hi! I stumbled upon this crate while researching some unrelated things, and it looks like it could make an excellent replacement for our ad-hoc atomics polyfill on Hubris for ARMv6-M.
However, our situation is slightly weird: as far as I can tell, we're some of the only folks in the embedded Rust world who are using the privileged/unprivileged modes of the processor. We're also using memory protection to isolate unprivileged tasks, and do not permit threading within a task.
This means our atomic polyfill within tasks winds up not generating the cpsid/cpsie instructions that you'd use in a threaded privileged context.
Would y'all be open to a PR adding an additional feature (with a name including the word unsafe and possibly some screaming) to suppress generation of the cpsid/cpsie instructions?
In systems with no interrupts or preemption, it is also sound even if replace the code that disables interrupts and restores interrupt state with a compiler fence, so I think it is ok to have a new unsafe cfg to do that.
Agreed, a compiler fence seems like the right tool. I'll send a PR when I have some time. Thanks!
By the way, you can also do this by enabling the critical-section feature of the portable-atomic and providing a critical-section implementation that just emits a compiler fence.
That said, since we cannot inline the critical-section implementation calls, a dedicated cfg would allow for more efficient code generation.