On Tuesday 02 November 2010 08:39:45 Hans Petter Selasky wrote: > 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. > > Hi John, > > 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? > > --HPS > > > 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). >
Any more comments on this matter or someone still doing review? --HPS _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"