[RFC] Outline of USB process integration in the kernel
Hans Petter Selasky
hselasky at c2i.net
Mon Nov 1 20:14:06 UTC 2010
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>
> > 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, &sc-
> > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off, &sc-
> > 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
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?
More information about the freebsd-arch