Possible interrupt footgun on multicore systems

[MabezDev]

Now that the interrupt is handled internally by the peripheral driver, the interrupt is configured for the core the driver is created on, which means if core 0 creates a driver and moves it to core 1, its interrupt will still be handled by core 0. Maybe this isn't a big deal, but we should document or avoid it entirely if possible.

[bjoernQ]

Maybe it would be good to have a way to specify which core the interrupt should be handled on.

IIRC we are considering removing the interrupt handler from the constructors and add set_interrupt_handler for all drivers instead. I guess having an additional parameter wouldn't be too bad, then. (Alternatively specify that on the #[handler] macro - don't know why but that doesn't sound good to me)

[MabezDev]

Maybe it would be good to have a way to specify which core the interrupt should be handled on.

Unfortunately I don't think this is possible, at least on Xtensa. The mapping of interrupts can be done, but enable has be done each CPU respectively.

After thinking about this, I don't think this is a real issue. I will submit a docs PR to inform users about this, then we can close this.

[MabezDev]

Re opening thanks to the new construction of async drivers and a great idea from @Dominaezzz (#2430 (comment)) we can do better than just documentation now.

[bugadani]

We can disallow Sending async drivers. We can disable interrupt handlers on the "other" core when setting a new one. However, we can't really prevent Sending a blocking driver that has set an interrupt handler without disallowing Sending drivers completely. I'm not sure this is a big deal and the other two cases will already have practical benefit.

If we ever get to implementing split interrupt control structs, we can (and should) also make the split driver !Send - this won't be hard, the auto trait mechanism allows us to just make Async and SplitBlocking implement !Send.

[Dominaezzz]

The idea of making async drivers !Send is because the interrupt handlers in the hal haven't been written to correctly handle cross core interactions.
The aim is just to make sure the async drivers work as expected. There's also the option of making the interrupt handlers core safe, which would allow the async drivers to be correctly Send, but it comes at a performance cost due to the synchronisation required.

For blocking drivers, I mostly see this as "it's up to the user to get it right".
It's just mildly confusing that the driver itself provides the API to set the interrupt handler, which gives the false sense of Send safety.
Ideally the underlying interrupt setting API should be used by the user directly, so send safety and core affinity becomes an obvious thing to consider.

SplitBlocking being !Send might be a little heavy handed, I think marking the interrupt control object itself as !Sync should be enough to force the user to do the right thing.

[MabezDev]

Adding the beta blocker label as we probably want to flesh out a design here before we get close to 1.0