Date: Thu, 26 Jun 2003 06:17:18 +0200 From: Bernd Walter <ticso@cicely12.cicely.de> To: "Louis A. Mamakos" <louie@TransSys.COM> Cc: freebsd-hackers@freebsd.org Subject: Re: USB, select/poll for ucom Message-ID: <20030626041717.GA62147@cicely12.cicely.de> In-Reply-To: <200306251858.h5PIwSW8017536@whizzo.transsys.com> References: <imp@bsdimp.com> <E19VCk7-000254-00@cs.huji.ac.il> <20030625.101549.78767546.imp@bsdimp.com> <200306251858.h5PIwSW8017536@whizzo.transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 25, 2003 at 02:58:28PM -0400, Louis A. Mamakos wrote: > I think the problem is that the USB hardware doesn't try to read data > from the peripheral until the user-mode code does a read(2) system > call. I had this problem with the ugen device. I would guess that > the ucom/umodem devices could use the tty clist infrastructure as > the intermediate buffer for data to be stuck into absent the user > application doing a read. ugen can't preread from the device because it has to be generic. And without the appilication to call read(2) it has absolutely no clue about the number of bytes that can be read without harming the device. There are many devices out there where the number of bytes that you request do matter. ucom is different - it has a device specific driver that knows the hardware and starts receiving bytes from the hardware once the application opens the device. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030626041717.GA62147>