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

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.

Thanks,
matthew