Alan Stern wrote:
On Fri, 14 Dec 2007, Phil Endecott wrote:
One observation: when my user-space control transfer times out in this
case, I don't even get the 8 bytes that I know the printer sent; the
copy_to_user() in devio.c's proc_control() is not called if
usb_control_message() returns an error. (I'm guessing that the kernel
has the partial data available at that point.) I noticed a similar
issue with babble; I have a device that returned two bytes when asked
for one (the mass storage number-of-luns IIRC) with the right value in
the first of those bytes; however, copy_to_user() is not called so that
data is inaccessible to a user driver. In the interests of a "level
playing field" between kernel and user-space drivers, should this be changed?
Actually it _is_ a level playing field. The USBDEVFS_CONTROL ioctl
calls the kernel's usb_control_message() routine, which returns the
error code if an error occurred and the number of bytes transferred if
there was no error. The number of bytes isn't made available when an
error happens; that's just as true for kernel drivers as for user
drivers.
OK, but the kernel driver can still look in the buffer even though it
doesn't know how much, if any, of it is actually valid; it might do
this as a "last chance" when talking to a broken device, e.g. my
printer. Right?
Phil.
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
