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

On Monday 01 November 2010 22:14:49 John Baldwin wrote:
> 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. 

Hi John,

No, this is not possible without keeping my own queue, which I want to avoid. 
By state-machine you mean remembering the last state as a separate variable 
and checking that in the task-callback, right? Yes, I do that in addition to 
the new queuing mechanism.

A task barrier does not solve my problem. The barrier in my case is always 
last in the queue. I need to pull out previously queued tasks and put them 
last. That is currently not supported. I do this because I don't want to have 
a FIFO signalling model, and a neither want the pure taskqueue, which only 
ensures execution, not order of execution when at the same priority.

Another issue: Won't the barrier model lead to blocking the caller once the 
task in question is being issued the second time?

--HPS

> 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).