Date: Sat, 29 Dec 2007 13:16:37 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Greg Troxel <gdt@ir.bbn.com> Cc: usb@freebsd.org Subject: Re: lpt(4) and non-blocking read Message-ID: <20071229021637.GV40785@server.vk2pj.dyndns.org> In-Reply-To: <rmibq8awcgy.fsf@fnord.ir.bbn.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Fri, Dec 28, 2007 at 07:50:37PM -0500, Greg Troxel wrote: >1) On a read system call, if there is any data already read, return it. >If not, invoke a read bulk transfer, and if it completes very quickly >return the data. If not, return EWOULDBLOCK. This perhaps fudges a bit >on non-blocking vs fast. > >2) On open, start a read transfer, and as each transfer completes, if >there is room in the input buffer, start a new one. On a read system >call, return whatever data is already in the buffer (and therefore start >a read transfer if space is newly freed). Option 1 would seem to be the safest and easiest. >Besides non-blocking reads, there's the issue of select/poll for read. >To make this work, I think approach #2 is needed, because if no read >transfer has been done, there's no way to know if there's data. An alternative approach would be to have poll/select-for-read initiate a read transfer if there is no data available (ie if the poll/select would block). Note that, at present, ulpt(4) on FreeBSD doesn't support any read buffering. I've been bitten by this and there's a patch in PR usb/91538 to implement read buffering. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHda4F/opHv/APuIcRAhK3AJ9QD9XD7Hvcz4LOUlhyb9lDD7O5jgCfe3jA si7Kxme2/Zq/bTO1ciDuoZU= =4Z8+ -----END PGP SIGNATURE-----home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071229021637.GV40785>