ucom_queue_command will issue commands for open/close, then wait on them
to be finished. In the spirit of playing it safe, allow
ucom_queue_command's wait to be interrupted in case the usb process gets
jammed up waiting on the hardware -- we can at least recover the user
thread that initiated it, even if we can't recover the usb process.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 61020 Build 57904: arc lint + arc unit
Event Timeline
| sys/dev/usb/usb_process.c | ||
|---|---|---|
| 409–442 | I have no idea about USB code, but I have an opinion. Suppose that we are waken by a signal, and suppose that pm_qentry links are gone. Shouldn't we avoid returning EINTR in this case, pretending that the entry was processed properly? This way the caller knows for sure was the entry processed or not. | |
Comment Actions
Override cv_wait_sig() errors if neither of the tasks are currently enqueued,
because the caller doesn't actually care beyond that..