-
Notifications
You must be signed in to change notification settings - Fork 87
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
Request: Add support for atomic-polyfill #114
Comments
While I theoretically want to implement this (I've worked with Rust on the GBA in the past) I'm a little worried about the possible soundness implications. From the
This seems to imply that enabling such a feature on a multi-core platform might accidentally result in Except when they don't opt into it. Cargo's dependency resolver unifies feature sets, and this may lead to a sub-dependency accidentally relying on unsound behaviour because a crate higher up in the dependency tree enables the feature. I don't really see a way out of this, cargo's feature system just isn't designed to deal with these sort of cases, and I'm not aware of a way to force the resolver not to unify when a specific feature flag is enabled. |
What do you suggest? I've been told |
One option might be to make #[cfg(feature = "building_for_the_gba")]
type Mutex<T> = spin::Mutex<T, DisableIrq>;
#[cfg(not(feature = "building_for_the_gba"))]
type Mutex<T> = spin::Mutex<T, Atomic>; Obviously, this won't work if you're depending on something that requires |
I would find it sufficient for this crate to state that enabling the Detecting the target to be multicore in Rust code is also impossible when you have heterogeneous cores that depend on Making |
Perhaps there is another, more sound solution, created by @taiki-e: This crate includes the following cfg flag:
This ensures that only the last link in the dependency chain has control and unintentional activation should be impossible. |
This is a good idea and seems like it would resolve my concerns! @Wassasin: if this was a route you wanted to go down, I'd be happy to accept the PR. |
This has now been implemented by #120, thanks to @fralalonde ! |
The Game Boy Advance is an ARMv4T platform with tier 3 support via the target triple
thumbv4t-none-eabi
. It's a single-threaded processor with no atomic instructions, so you have to use theatomic-polyfill
crate and provide a custom implementation of a critical section which disables interrupts for the duration of an atomic operation.This crate assumes it can find atomic types in the core library and therefore fails on this platform. Would you be willing to add a feature flag to support
atomic-polyfill
?The text was updated successfully, but these errors were encountered: