From owner-freebsd-usb@FreeBSD.ORG Thu Nov 4 13:55:12 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 B482A1065679; Thu, 4 Nov 2010 13:55:12 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BD15E8FC12; Thu, 4 Nov 2010 13:55:10 +0000 (UTC) Received: by iwn39 with SMTP id 39so1442199iwn.13 for ; Thu, 04 Nov 2010 06:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rc6Kf9M4JbqxPQwsiLamXqjZv7hw7qPAbMGIlSL8Prc=; b=lhInRB7GhpdX3uDnyYrOVphBArMV2tL/Uyd60gDHexCc0bXEUPLArOOZgiPRa1Tw/Z OL6h6Vh4BK82OvnMVa2HnpY65OizkAZw9OAxbugup/eNIGmBj43kVwUV4tejVGwL7xjk ttInqLtFa5GrjknG6B8g9TvE0Bb5E9pB8RikA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=is+GRIxG7FlicA8x+7DoC0R9Po5VylH8eu3ln0WTPSFoslwaXPNqJm9he0jJ8/8okT ABuI7NcHTSztRM6vRgUI9YFBWEs7OKjjNKuZCkxzJyFKl1l/SOgiEJLznrln8f+rusZ7 HoR+lUKhuu3qSw++keX/shCIhz7yvui16KNNI= MIME-Version: 1.0 Received: by 10.231.33.203 with SMTP id i11mr490075ibd.8.1288878909370; Thu, 04 Nov 2010 06:55:09 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Thu, 4 Nov 2010 06:55:09 -0700 (PDT) In-Reply-To: <201011012115.15261.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011012115.15261.hselasky@c2i.net> Date: Thu, 4 Nov 2010 06:55:09 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, 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 13:55:12 -0000 On Mon, Nov 1, 2010 at 1:15 PM, Hans Petter Selasky wrot= e: > 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 integrat= e >> > 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? =A0Many taskqueue(9) consumer= s do >> not. > > No, USB does not need a task priority field, but a sequence field associa= ted > with the task and task queue head to figure out which task was queued fir= st > 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 whic= h > 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. Thanks, matthew