Change Details

Instead of maintaing two event and using self-defined process. We integrate the code to taskqueue code in our kernel. This makes our usb async code easier to maintain.

Previously, the USB async process implemented its own worker and event handling. This design allowed all USB code to hold the mutex while events were being processed. However, the async process is not used directly: transfer, enumeration, and initilization are all wrapped internally, so driver developers do not need to manage it themselves. This change decouples the mutex from the USB sync thread, reducing the size of critical sections. The tradeoff is that any custom async thread implementation must now handle locking explicitly. The implementation is also clearer by using taskqueue.

Instead of maintaing two event and using self-defined process. Previously, the USB async process implemented its own worker and event handling. This design allowed all USB code to hold the mutex while events were being processed. However, the async process is not used directly: transfer, enumeration, and initilization are all wrapped internally, We integrate the code to taskqueue code in our kernelso driver developers do not need to manage it themselves. This change decouples the mutex from the USB sync thread, reducing the size of critical sections. This makes our usb async code easier to maintaine tradeoff is that any custom async thread implementation must now handle locking explicitly. The implementation is also clearer by using taskqueue.