On Monday, November 01, 2010 3:54:59 pm Hans Petter Selasky wrote:
> I've wrapped up an outline patch for what needs to be done to integrate the
> USB process framework into the kernel taskqueue system in a more direct way
> that to wrap it.
> The limitation of the existing taskqueue system is that it only guarantees
> execution at a given priority level. USB requires more. USB also requires a
> guarantee that the last task queued task also gets executed last. This is for
> example so that a deferred USB detach event does not happen before any
> deferred I/O for example in case of multiple occurring events.
> Mostly this new feature is targeted for GPIO-alike system using slow busses
> like the USB. Typical use case:
> 2 tasks to program GPIO on.
> 2 tasks to program GPIO off.
> a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on, &sc-
> b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off, &sc-
> No matter how the call ordering of code-line a) and b), we are always
> guaranteed that the last queued state "on" or "off" is reached before the
> of the taskqueue empties.
> In lack of a better name, the new function was called taskqueue_enqueue_odd
> [some people obviously think that USB processes are odd, but not taskqueues
It feels like this should be something you could manage with a state machine
internal to USB rather than forcing that state into the taskqueue code itself.
If you wanted a simple barrier task (where a barrier task is always queued at
the tail of the list and all subsequent tasks are queued after the barrier task)
then I would be fine with adding that. You could manage this without having
to alter the task KBI by having the taskqueue maintain a separate pointer to
the current "barrier" task and always enqueue entries after that task (the
barrier would be NULL before a barrier is queued, and set to NULL when a
I think this sort of semantic is a bit simpler and also used in other parts of
the tree (e.g. in bio queues).
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"