lpt(4) and non-blocking read

[Peter Jeremy]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-usb/attachments/20071229/704a16b0/attachment.pgp