Re: [RFC] Outline of USB process integration in the kernel taskqueue system

On Monday, November 01, 2010 3:54:59 pm Hans Petter Selasky wrote:
> Hi!
> 
> 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 pending 
> 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.
> 
> Example:
> 
> a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc-
> >sc_task_on[1]);
> 
> 
> b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc-
> >sc_task_off[1]);
> 
> 
> 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 head 
> 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
barrier executes).

I think this sort of semantic is a bit simpler and also used in other parts of
the tree (e.g. in bio queues).

-- 
John Baldwin