Optional unprivileged even-more-unsafe mode for certain use cases?

[cbiffle]

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?

[taiki-e]

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.

[cbiffle]

Agreed, a compiler fence seems like the right tool. I'll send a PR when I have some time. Thanks!

[taiki-e]

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.