From owner-freebsd-usb@FreeBSD.ORG Sun Feb 1 20:57:47 2009 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 AA019106566C; Sun, 1 Feb 2009 20:57:47 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.swipnet.se [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id 0F0938FC0C; Sun, 1 Feb 2009 20:57:46 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=DnD7uB8Qd4W-3mlJOqsA:9 a=auK1lcAOoKIF5W0oCTEA:7 a=akk9JPSbfJFmxdYgaFHfGFSJglUA:4 a=50e4U0PicR4A:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 446179965; Sun, 01 Feb 2009 21:57:45 +0100 From: Hans Petter Selasky To: Andrew Thompson Date: Sun, 1 Feb 2009 22:00:10 +0100 User-Agent: KMail/1.9.7 References: <200902011220.18745.hselasky@c2i.net> <200902012031.56899.hselasky@c2i.net> <20090201195859.GH32503@citylink.fud.org.nz> In-Reply-To: <20090201195859.GH32503@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902012200.11499.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: USB2 patches 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: Sun, 01 Feb 2009 20:57:48 -0000 Hi Andrew, > > > > This is not correct. The queuing mechanism in USB2 guarantees that the > > last queued command is last executed: > > There are a few options, > > - coalesce on a single task (on,off,on = on), the off never happened. > - drain the task first then resubmit > > Those cover both scenarios, (1) you dont care about previous state or > (2) you do care so ensure the previous state has executed. > "2" is not an option. MPSAFETTY cannot sleep! And there is no IOCTL to drain the DTR command, if I'm not mistaken. > If for some reason those are not sufficient then the driver is free to > implement its own queue. We don't want per-driver queues. We want one queue mechanism for USB. Like I've pointed out, last queued is last executed is a good requirement. For simple things like DTR, sure you could coalesque state changes, but again, that is not optimal, because it is unpredictable. Also see my other e-mail with same subject to Warner. It's like with queues. There is SLIST, LIST, TAILQ, STAILQ. Different need needs different macro. The same should be the case with taskqueues. I have looked at the internals of the taskqueue and the only reordering mechanism is a priority mechanism. To some extent my implementation is about dynamic and efficient priority re-ordering of messages. The taskqueue_enqueue() can have a complexity of X squared, X*X, given the iteration accross the messages already queued, in some cases. Mine has a complexity of 1. What do you think? Is it impossible to add another queue function to the taskqueue system? > The current implementation in usb is quite > clever but its important not to complicate the internals for situations > that dont happen in real life. I would argue that the taskqueue approach is too simple for USB. --HPS