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

On Monday 01 November 2010 21:07:29 Matthew Fleming wrote:
> On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky <hselasky_at_c2i.net> 
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
> > 
> > :-)]
> 
> I'd like to make sure I understand the USB requirements.
> 
> (1) does USB need the task priority field?  Many taskqueue(9) consumers do
> not.

No, USB does not need a task priority field, but a sequence field associated 
with the task and task queue head to figure out which task was queued first 
without having to scan all the tasks queued.

> (2) if there was a working taskqueue_remove(9) that removed the task
> if pending or returned error if the task was currently running, would
> that be sufficient to implement the required USB functionality?
> (assuming that taskqueue_enqueue(9) put all tasks with equal priority
> in order of queueing).

No, not completely. See comment above. I also need information about which 
task was queued first, or else I have to keep this information separately, 
which again, confuse people. The more layers the more confusion?

--HPS