Date: Thu, 4 Nov 2010 10:29:51 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: Matthew Fleming <mdf356@gmail.com>, Andrew Thompson <thompsa@freebsd.org>, Weongyo Jeong <weongyo.jeong@gmail.com>, freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Hans Petter Selasky <hselasky@c2i.net> Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system Message-ID: <201011041029.51864.jhb@freebsd.org> In-Reply-To: <AANLkTi=83-ZALkn2T-g_DnbfSPF-MGz14Bp%2BDN-9toZp@mail.gmail.com> References: <201011012054.59551.hselasky@c2i.net> <201011012115.15261.hselasky@c2i.net> <AANLkTi=83-ZALkn2T-g_DnbfSPF-MGz14Bp%2BDN-9toZp@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, November 04, 2010 9:55:09 am Matthew Fleming wrote: > On Mon, Nov 1, 2010 at 1:15 PM, Hans Petter Selasky <hselasky@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@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. My sense is that I certainly agree. The fact that you can't think of a good name for the operation certainly indicates that it is not generic. Unfortunately, I don't really understand the problem that is being solved. I do agree that due to the 'pending' feature and automatic-coalescing of task enqueue operations, taskqueues do not lend themselves to a barrier operation. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201011041029.51864.jhb>