Remove CoreSend/CoreSync from proposal

Author: jonas-schievink

rfcs/0000-multi-core-soundness.md

@@ -12,12 +12,11 @@ Change how we model multi-core MCUs in the following ways:
   interactions since those traits are unfit for the purpose.
 * Declare that `Send` is not sufficient to transfer resources between cores,
   since memory addresses can have different meanings on different cores.
-* Introduce `CoreSend` and `CoreSync` traits to the [`bare-metal`] crate.
-* Require multi-core PACs/HALs, frameworks and/or libraries to manually mark
-  data that is safe to send across core boundaries.
 * Mutexes based on critical sections become declared sound due to the above:
   They can only turn `Send` data `Sync`, but neither allows cross-core
   interactions anymore.
+* Punt on how to deal with cross-core communication and data sharing for now,
+  and leave it to the ecosystem.
 
 # Motivation
 [motivation]: #motivation
@@ -102,59 +101,20 @@ risk of the resources changing their meaning when sent.
 # Detailed design
 [design]: #detailed-design
 
-## Introduce common traits for modeling cross-core operations
-
-The following trait definitions and impls will be added to [`bare-metal`]:
-
-```rust
-/// Types that can be transferred across core boundaries.
-pub unsafe trait CoreSend {}
-
-/// Types that can be accessed from multiple cores at once.
-pub unsafe trait CoreSync {}
-
-unsafe impl<'a, T: CoreSync> CoreSend for &'a T {}
-```
-
-Note that these are not auto traits. That is not just because auto traits are
-still an unstable feature, but also because that wouldn't be correct: As
-outlined in [Today's Soundness Issues][todays-issues], whether some data is safe
-to be sent between cores depends not just on its type contents, but also on its
-location in memory.
-
-It is only safe to implement `CoreSync` if *all* instances of the implementing
-type will either be at memory locations shared by all cores, or are zero-sized.
-Similarly, it is only safe to implement `CoreSend` if *all* instances of the
-implementing type contain only data that is safe to send to another core (which
-moves the value in memory). Of course, the type's API must also ensure that no
-memory accesses to core-local memory occur (important for eg. core-local
-peripherals).
-
-### `CoreSend`
-
-It is expected that `CoreSend` will be implemented for peripherals shared
-between all cores in the system, and also by HAL wrappers of those peripherals,
-so that applications can transfer such peripherals to any core in the system.
-This RFC does not mandate how exactly those implementations will be written or
-generated. One option would be to give `svd2rust` an unsafe command line flag to
-generate `CoreSend` for all peripherals.
-
-For example, `CoreSend` would be implemented by all peripherals of the LPC5411x,
-which has a Cortex-M4 and a Cortex-M0+ core sharing all non-core peripherals. It
-would *not* be implemented by the peripherals of the nRF5340, which has two
-cores that have independent peripherals (each core owns its peripherals).
+## Document what `Send` and `Sync` mean
 
-`CoreSend` is expected to be used as a trait bound by support libraries, HALs
-and frameworks such as [µAMP] that provide support for multi-core processors.
-For example, an API could be built that consumes `CoreSend` types and passes
-them to the entry point of the secondary core.
+`Send` and `Sync` will be used only to model transfer and sharing of resources
+between different *execution contexts* that run with the same fixed set of
+global resources.
 
-### `CoreSync`
+Here, an *execution context* is something that may execute code asynchronously
+from other code (so without needing to be called). For example, a *thread* or
+an *interrupt handler* would qualify as an *execution context*, while a
+single-threaded futures executor would *not* create any more *execution
+contexts* while it executes.
 
-The `CoreSync` trait is expected to be used for sharing *data* between cores.
-A framework like [µAMP] could generate a controlled wrapper type around shared
-data placed in a known section, and have that wrapper implement `CoreSync`,
-allowing the application to copy references to the data between cores.
+Concretely (for embedded Rust), that means `Send` and `Sync` can be used to
+model threads in an RTOS, or interrupt handlers for bare-metal applications.
 
 ## `bare_metal::Mutex` is now sound
 
@@ -175,34 +135,16 @@ In SMP apps, only a single executable is used for all cores, while each core can
 have a separate entry point (or another mechanism of identifying the running
 core). This means that all `static`s are shared by default.
 
-Since defining a `static` only requires that its type is `Sync`, not `CoreSync`,
-this would be unsound. For example, it would allow storing a `bare_metal::Mutex`
-in a `static` and access it from all cores. Therefore, this RFC foregoes the
-ability to write safe SMP apps in Rust, instead proposing to shift focus to AMP
-apps, which do not share data by default and produce a separate executable per
-core.
+Since defining a `static` only requires that its type is `Sync`, this would be
+unsound. For example, it would allow storing a `bare_metal::Mutex` in a `static`
+and access it from all cores. Therefore, this RFC foregoes the ability to write
+safe SMP apps in Rust, instead proposing to shift focus to AMP apps, which do
+not share data by default and produce a separate executable per core.
 
 # How We Teach This
 [how-we-teach-this]: #how-we-teach-this
 
-API documentation of `CoreSend` and `CoreSync` needs to be clarified. The
-single-sentence documentation above is not meant to be complete.
-
-## Document what `Send` and `Sync` mean
-
-`Send` and `Sync` will be used only to model transfer and sharing of resources
-between different *execution contexts* that run with the same fixed set of
-global resources.
-
-Here, an *execution context* is something that may execute code asynchronously
-from other code (so without needing to be called). For example, a *thread* or
-an *interrupt handler* would qualify as an *execution context*, while a
-single-threaded futures executor would *not* create any more *execution
-contexts* while it executes.
-
-Concretely (for embedded Rust), that means `Send` and `Sync` can be used to
-model threads in an RTOS, or interrupt handlers for bare-metal applications.
-
+(see above)
 
 # Drawbacks
 [drawbacks]: #drawbacks
@@ -218,29 +160,27 @@ model threads in an RTOS, or interrupt handlers for bare-metal applications.
   expected that the actual cross-core communication is limited to a small number
   of places in the code, so making it more difficult has limited impact.
 
-* `CoreSend` and `CoreSync` do not handle hypothetical cases in which
-  peripherals or memory are shared between a *subset* of all cores. Examples of
-  devices that have a configuration like this would be very welcome.
+* This RFC generally rules out SMP apps that run the same firmware image on
+  multiple cores. These would be able to share data via `static`s, which only
+  requires a `Sync` bound, and that is not sufficient to guarantee safe
+  operation when accessed from multiple cores.
 
 # Alternatives
 [alternatives]: #alternatives
 
 * Accept [RFC 388] instead, introducing a `SingleCore{Send,Sync}` auto trait
   pair once auto traits are stable, and make `Mutex::new` an `unsafe fn` in the
   interim. Remove unsound `Send` impls from peripherals.
-* Do what this RFC proposes, but without the common `CoreSend`/`CoreSync`
-  traits. Leave it to the ecosystem to find the right abstractions for
-  multi-core MCUs.
-* Change the definition/contract of `CoreSync` to be "implements `Sync` and lies
-  in and touches only memory accessible to all cores", which would mean that SMP
-  apps could be supported while `bare_metal::Mutex` would still only be sound on
-  single-core MCUs.
+
+* Do what this RFC proposes, and also introduce `CoreSend`/`CoreSync` traits to
+  model cross-core interaction. (This was what this RFC initially proposed, but
+  it was decided that we should focus on fixing the soundness issues first and
+  leave multi-core support to be implemented outside the core ecosystem.)
 
 # Unresolved questions
 [unresolved]: #unresolved-questions
 
-* Should `CoreSend` and `CoreSync` have `Send` and `Sync` as supertraits?
-* Should we provide `CoreSend` implementations for primitive types?
+* None so far.
 
 [`bare_metal::Mutex`]: https://docs.rs/bare-metal/0.2.5/bare_metal/struct.Mutex.html
 [RFC 388]: https://github.com/rust-embedded/wg/pull/388