fix(embassy-init): move out peripherals required for drivers earlier

[ROMemories]

Description

Previously, it would have been possible for user tasks to take peripherals out of OptionalPeripherals before the required peripherals had been extracted for drivers.
This now takes the peripherals before starting the user tasks, making this impossible for tasks.

Issues/PRs references

N/A

Open Questions

None.

Change checklist

• I have cleaned up my commit history and squashed fixup commits.
• I have followed the Coding Conventions.
• I have performed a self-review of my own code.
• I have made corresponding changes to the documentation.

[ROMemories]

I renamed this function for consistency with other driver modules; this is not a breaking change as this module is private.

[ROMemories]

Marking as draft as this requires a separate PR to improve the macro error message, that would need to be landed first.

[elenaf9]

Style: move imports to top of file.

[ROMemories]

I'd rather keep this import closer to its usage locations, given that its usage is non-obvious.

[ROMemories]

This definition is what triggers the different macro error message. As the error message is clearer this way, this doesn't seem like an issue.

[ROMemories]

Unmarking as draft as the different error message is only due to defining Peripherals in the dummy usb module; it doesn't make sense to move that change to a separate PR.

[kaspar030]

I'm not sure I agree with this direction.

1. this makes some parts of the system special ("ours"), demoting user code. IMO this shouldn't be the case, we should rather try harder to build our components on what we offer to users.
2. this is, imo, clumsier to use. Now there's an extra define_peripherals!() for a lot of cases where there is only one (or even no) peripheral used.

[ROMemories]

this makes some parts of the system special ("ours"), demoting user code

I'm not sure I understand your comment; this only changes part of the driver initialization, fixing bugs in case users enabled specific drivers through Cargo features (e.g., usb), but also attempted to extract the required peripherals in users tasks, in which case the following would panic:

RIOT-rs/src/riot-rs-embassy/src/arch/nrf/usb.rs

Lines 26 to 27 in e44eaca

	pub fn driver(peripherals: &mut arch::OptionalPeripherals) -> UsbDriver {
	let usbd = peripherals.USBD.take().unwrap();

By moving out peripherals earlier, before user tasks, this prevents this panic in drivers; instead the users' .take() would return a None for those peripherals, as they would already be taken.

this is, imo, clumsier to use. Now there's an extra define_peripherals!() for a lot of cases where there is only one (or even no) peripheral used

This is only driver initialization; the Peripherals struct only need to be defined for drivers that require at least one peripheral on one of the architectures.

[kaspar030]

By moving out peripherals earlier, before user tasks, this prevents this panic in drivers; instead the users' .take() would return a None for those peripherals, as they would already be taken.

Hmya, the user code would then most likely panic in its .unwrap() of that None, we successfully protected "system" (our) code. That's what I mean. There'll be a panic in any case.

This practically moves back taking / splitting of the peripherals back into a central function, but in a way that "users" cannot replicate, b/c they're bound to tasks that only get the full OptionalPeripherals.

We're basically chickening out of handling our .take().unwrap()s properly. So, I'm not convinced this is desirable.

[kaspar030]

So, I'm not convinced this is desirable.

What I think might be preferable would be a way to track where peripherals were taken (e.g., modify "take()" to trace!() where it was called if nudged to to so by, e.g., sth like CONFIG_PERIPH_TRACE=PA15,USBD).

[kaspar030]

user tasks

we could also have two task lists, one for those that need to hook into the regular init, and one "default" that is only started after all regular init has taken place.

[ROMemories]

Hmya, the user code would then most likely panic in its .unwrap() of that None, we successfully protected "system" (our) code. That's what I mean. There'll be a panic in any case.

This practically moves back taking / splitting of the peripherals back into a central function, but in a way that "users" cannot replicate, b/c they're bound to tasks that only get the full OptionalPeripherals.

These early peripherals extractions are feature-gated the same way the associated drivers are. When users enable driver Cargo features, this implies asking us to handle the required peripherals; so if users also try to obtain the peripherals required for that driver, it's a bug in users' code. Users still have full access to all peripherals, unless they enable driver Cargo features.