Date: Mon, 1 Nov 2010 21:15:15 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: Matthew Fleming <mdf356@gmail.com> Cc: freebsd-current@freebsd.org, Weongyo Jeong <weongyo.jeong@gmail.com>, freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system Message-ID: <201011012115.15261.hselasky@c2i.net> In-Reply-To: <AANLkTi=uA3t8YHNWU_D37c57E=dvbxBQ7FdgRK4h3h5O@mail.gmail.com> References: <201011012054.59551.hselasky@c2i.net> <AANLkTi=uA3t8YHNWU_D37c57E=dvbxBQ7FdgRK4h3h5O@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 01 November 2010 21:07:29 Matthew Fleming wrote: > On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky <hselasky@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? --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201011012115.15261.hselasky>