On Monday 01 November 2010 22:14:49 John Baldwin wrote:
> On Monday, November 01, 2010 3:54:59 pm Hans Petter Selasky 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, &sc-
> > >sc_task_on);
> > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off, &sc-
> > >sc_task_off);
> > 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
> > :-)]
> It feels like this should be something you could manage with a state
> machine internal to USB rather than forcing that state into the taskqueue
> code itself.
No, this is not possible without keeping my own queue, which I want to avoid.
By state-machine you mean remembering the last state as a separate variable
and checking that in the task-callback, right? Yes, I do that in addition to
the new queuing mechanism.
A task barrier does not solve my problem. The barrier in my case is always
last in the queue. I need to pull out previously queued tasks and put them
last. That is currently not supported. I do this because I don't want to have
a FIFO signalling model, and a neither want the pure taskqueue, which only
ensures execution, not order of execution when at the same priority.
Another issue: Won't the barrier model lead to blocking the caller once the
task in question is being issued the second time?
> If you wanted a simple barrier task (where a barrier task is
> always queued at the tail of the list and all subsequent tasks are queued
> after the barrier task) then I would be fine with adding that. You could
> manage this without having to alter the task KBI by having the taskqueue
> maintain a separate pointer to the current "barrier" task and always
> enqueue entries after that task (the barrier would be NULL before a
> barrier is queued, and set to NULL when a barrier executes).
> I think this sort of semantic is a bit simpler and also used in other parts
> of the tree (e.g. in bio queues).
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"