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

On Tuesday 02 November 2010 08:39:45 Hans Petter Selasky wrote:
> 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).
> 

Any more comments on this matter or someone still doing review?

--HPS