From owner-freebsd-usb@FreeBSD.ORG Thu Nov 4 15:08:52 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D81761065672; Thu, 4 Nov 2010 15:08:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id CAFDE8FC16; Thu, 4 Nov 2010 15:08:51 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5OBHFxb9I47YZ7HELXzI6cL6pwPTRnd5uxbD1DPQ4WY= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=eBBTKOCzzS4ddj3yubgA:9 a=UVoTL3aoASoHr0WDeJkA:7 a=nXYsBsMJQ5gLzLLRCrZL-R1_Wg0A:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44175068; Thu, 04 Nov 2010 16:08:49 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Thu, 4 Nov 2010 16:10:00 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011012115.15261.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011041610.00736.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Matthew Fleming , freebsd-usb@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 15:08:53 -0000 On Thursday 04 November 2010 14:55:09 Matthew Fleming wrote: > On Mon, Nov 1, 2010 at 1:15 PM, Hans Petter Selasky wrote: > > On Monday 01 November 2010 21:07:29 Matthew Fleming wrote: > >> On Mon, Nov 1, 2010 at 12:54 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[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? Hi, > > 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. Probably I can check which task is pending when I queue them and store that in a separate variable. Still I need a way to remove a task from the queue, which becomes very slow due to the fact that STAILQ() is used. > To my mind, there's primary operations, and secondary ones. A > secondary operation can be built from the primary ones. That is right, if there is a way to remove a task from a queue without draining. > 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. The only reason I want to break the KBI is because it is slow to remove a task from the taskqueue using STAILQ's when you don't know the previous task- element in the queue. --HPS