Adjust API to allow `UsbDevice` and `UsbClass`-es to be `Send` without wrapping every `UsbBus` implementation method in a critical section

[FeldrinH]

Currently every UsbBus implementation that I am aware of is Sync and it synchronizes access by wrapping most UsbBus methods in a critical section. This can cause latency issues, because it means that during USB reads, writes and polling any higher priority interrupt handlers will be delayed. This has been a problem in practice (see stm32-rs/stm32-usbd#32, stm32-rs/synopsys-usb-otg#27).

In theory a UsbBus could be implemented which is not Sync, as the Sync bound was removed in #149. Unfortunately, in practice such a UsbBus ends up being extremely restrictive. This is because UsbDevice and UsbClass-es contain a reference to UsbBus and if UsbBus isn't Sync then &UsbBus isn't send and therefore UsbDevice and UsbClass-es using the bus aren't Send. This means that there is no safe way to move them into interrupt handlers or elsewhere, even with mutexes and other synchronization. This rules out practically any architecture except for using UsbDevice and UsbClass-es in the main loop.

Given all this, there is a practical need for a way to implement UsbBus without critical sections everywhere while still allowing you to move UsbDevice and UsbClass-es to other threads.

My main claim is this:
I believe it isn't possible for individual UsbBus implementations to fix this problem on their own. There is a need to adjust the usb-device API to resolve this.

I don't have a specific proposal, but I have two high-level solution outlines:

1. Split UsbBus into components which can be owned exclusively by UsbDevice and UsbClass-es. E.g. the UsbDevice would have exclusive ownership of the core USB registers (interrupts, statuses and whatnot) and each UsbClass would have exclusive ownership of its own endpoints. Since all endpoints are allocated ahead of time there should be minimal interaction between these components at runtime and thus minimal need for synchronization using critical sections.

2. Make UsbDevice exclusively own the UsbClass-es. This would allow UsbDevice to exclusively own the entire UsbBus, thus requiring no synchronization. (This is compatible with solution 2 from this semi-related issue: Figure out a better way to keep track of the list of classes #9.)

I would love to have some feedback on what people think of this. Can this be done? Should this be done? Is anyone using workarounds for this in practice and if so what are these workarounds?

[ianrrees]

Thanks for the work on this, as in #9, I'm a fan of your outline 2.

My feeling is that there are two stages to this: first is to have the bus own the class instances. In this work, we'd need to provide an example of a useful class that doesn't require mutable access to the bus (eg using bbqueue to move CDC data). Then, rework the usb-device API so that it is a bit more ergonomic in terms of lifetimes and Send/Sync requirements.

My workaround for an ATSAMD21 project I worked on a few years ago (which didn't ever get shipped, but was used quite a bit in testing), was to fork usb-device and the ATSAMD HAL, hack out all the Send+Sync requirements in that fork, and after construction only accessed the USB state from an ISR context. Data was moved in/out of the USB via either bbqueue or a custom thing I made that works effectively the same way.

[parasyte]

I believe this would resolve #105 as well.

Can this be done?

Unfortunately, I have not reviewed the code (I'm a drive-by commenter with a library user POV), so I cannot comment on feasibility.

Should this be done?

Yes. 💯 As long as there are no blockers, I am fully supportive of a disciplined ownership story for UsbBus.

I have a workaround that avoids move-while-borrowed errors when trying to encapsulate all of the USB initialization code. These types (UsbDevice, UsbBus, etc.) cannot be returned from a function, so I use a declarative macro instead. (Sync is not an issue for my use case, but the borrowing in general is.)