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

On Thursday, November 04, 2010 9:55:09 am 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?
> 
> 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.
> 
> To my mind, there's primary operations, and secondary ones.  A
> secondary operation can be built from the primary ones.  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.

My sense is that I certainly agree.  The fact that you can't think of a good
name for the operation certainly indicates that it is not generic.
Unfortunately, I don't really understand the problem that is being solved.

I do agree that due to the 'pending' feature and automatic-coalescing of
task enqueue operations, taskqueues do not lend themselves to a barrier
operation.

-- 
John Baldwin