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

On Thursday 04 November 2010 14:55:09 Matthew Fleming wrote:
> On Mon, Nov 1, 2010 at 1:15 PM, Hans Petter Selasky <hselasky_at_c2i.net> 
wrote:
> > 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?

Hi,

> 
> I don't follow why keeping the information about which task was queued
> first privately rather than having taskqueue(9) maintain it is
> confusing.  So far, USB seems to be the only taskqueue consumer which
> needs this information, so it makes a lot more sense to me for it to
> be USB private.

Probably I can check which task is pending when I queue them and store that in 
a separate variable. Still I need a way to remove a task from the queue, which 
becomes very slow due to the fact that STAILQ() is used.

> To my mind, there's primary operations, and secondary ones.  A
> secondary operation can be built from the primary ones. 

That is right, if there is a way to remove a task from a queue without 
draining.

> It reads to
> me that, if there was a taskqueue_cancel(9) (and there is in Jeff's
> OFED branch) then you could build the functionality you want (and
> maybe you don't need cancel, even).  While there is sometimes an
> argument for making secondary operations available in a library, in
> this case you need extra data which most other taskqueue consumers do
> not.  That would break the KBI.  That is another argument in favor of
> keeping the implementation private to USB.

The only reason I want to break the KBI is because it is slow to remove a task 
from the taskqueue using STAILQ's when you don't know the previous task-
element in the queue.

--HPS