From owner-cvs-src@FreeBSD.ORG Wed Oct 20 06:10:28 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A3C5916A4CE; Wed, 20 Oct 2004 06:10:27 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i9K6ARH5020567; Wed, 20 Oct 2004 02:10:27 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i9K6AQLW020566; Wed, 20 Oct 2004 02:10:26 -0400 (EDT) (envelope-from green) Date: Wed, 20 Oct 2004 02:10:26 -0400 From: Brian Fundakowski Feldman To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Message-ID: <20041020061026.GH1072@green.homeunix.org> References: <200410130412.i9D4CK7v065761@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410130412.i9D4CK7v065761@repoman.freebsd.org> User-Agent: Mutt/1.5.6i cc: current@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/usb ugen.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: current@FreeBSD.org List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 06:10:28 -0000 On Wed, Oct 13, 2004 at 04:12:20AM +0000, Brian Feldman wrote: > green 2004-10-13 04:12:20 UTC > > FreeBSD src repository > > Modified files: > sys/dev/usb ugen.c > Log: > Back out rev.1.91 which implemented bulk read transfers in ugen(4) as > asynchronous. I realize that this means the custom application will > not work as written, but it is not okay to break most users of ugen(4). > > The major problem is that a bulk read transfer is not an interrupt > saying that X bytes are available -- it is a request to be able to > receive up to X bytes, with T timeout, and S short-transfer-okayness. > > The timeout is a software mechanism that ugen(4) provides and cannot > be implemented using asynchronous reads -- the timeout must start at > the time a read is done. > > The status of up to how many bytes can be received in this transfer > and whether a short transfer returns data or error is also encoded > at least in ohci(4)'s requests to the controller. Trying to detect > the "maximum width" results in using a single buffer of far too > small when an application requests a large read. > > Even if you combat this by replacing all buffers again with the > maximal sized read buffer (1kb) that ugen(4) would allow you to > use before, you don't get the right semantics -- you have to > throw data away or make all the timeouts invalid or make the > short-transfer settings invalid. > > There is no way to do this right without extending the ugen(4) API > much further -- it breaks the USB camera interfaces used because > they need a chain of many maximal-width transfers, for example, and > it makes cross-platform support for all the BSDs gratuitously hard. > > Instead of trying to do select(2) on a bulk read pipe -- which has > neither the information on desired transfer length nor ability to > implement timeout -- an application can simply use a kernel thread > and pipe to turn that endpoint into something poll-able. > > It is unfortunate that bulk endpoints cannot provide the same semantics > that interrupt and isochronous endpoints can, but it is possible to just > use ioctl(USB_GET_ENDPOINT_DESC) to find out when different semantics > must be used without preventing the normal users of the ugen(4) device > from working. For what it's worth, it really isn't that hard to make your software account for bulk-ugen(4)'s brain-deadedness; for example, I can use this to do GPRS on my Treo with ppp(8): (I guess it's also useful as a reference implementation for this sort of thing in PPP, in general -- it certainly exposes weaknesses.) -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\