Date: Fri, 28 Dec 2007 19:50:37 -0500 From: Greg Troxel <gdt@ir.bbn.com> To: usb@freebsd.org Subject: lpt(4) and non-blocking read Message-ID: <rmibq8awcgy.fsf@fnord.ir.bbn.com>
next in thread | raw e-mail | index | archive | help
--=-=-= I didn't cross-post because I am guessing that wouldn't be appreciated, but I wanted to ask for advice here too. The NetBSD and FreeBSD ulpt(4) code is nearly identical, modulo os-adaptation issues, so the message applies equally to FreeBSD. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline From: Greg Troxel <gdt@ir.bbn.com> To: tech-kern@netbsd.org Subject: ulpt(4) and non-blocking read Date: Fri, 28 Dec 2007 19:48:19 -0500 Message-ID: <rmiir2iwcks.fsf@fnord.ir.bbn.com> MIME-Version: 1.0 The USB printer driver supports reading, but doesn't support nonblocking IO, which means it doesn't work with gutenprint. I have posted a similar note to the gutenprint list. Does anyone feel ownership of src/sys/dev/ulpt.c? Invoking a bulk transfer on an input endpoint can have side effects on some devices, so some drivers avoid such reads unless a read operation has been invoked. On other devices, queuing a read transfer is normal. So: on USB printers, is it ok to start a read bulk transfer just because the device is open? There are two approaches: 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). 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. Linux's drivers/usb/class/usblp.c seems to do a blend of these, starting a transfer on read, and restarting one on completion, but not starting one on the open call. NetBSD and FreeBSD both fail to support nonblocking read at all. OpenBSD seems to have an older ulpt that does not support reading at all. Opensolaris appears not to support nonblocking reads, but I could be wrong as I am not familiar with the codebase. Option 1 is easier, and could probably be done by modifying the existing loop to return after the first iteration whether the transfer succeeds or not. So I'll probably try that first. Any comments on the approach, or pointing out any confusion on my part, would be appreciated. --=-=-=--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?rmibq8awcgy.fsf>