FWIW, i found the recent display just fine with the exception of one field i was not sure about.
were i to change it, i might just add a bit of text after the actual_length=0 (ok during submission phase)
so i'd be clear on the fact that this indication is ok in this context.
beyond that, you maintainers know where the most common errors are found by developers,
those are the data points to be highlighted. if there are any potentially failing indications not
dumped during the usbfs_snoop, they'd be good to add.
i'm going to snoop more and maybe get more useful suggestions with some use...
hth, jackc...
Alan Stern wrote:
When people use usbfs_snoop to watch URBs coming from userspace, the
display isn't very sensible.
The USBDEVFS_BULK and USBDEVFS_CONTROL ioctls dump their data in two
slightly different formats. USBDEVFS_SUBMITURB dumps the data twice
(which makes no sense) in yet a different format and without paying
attention to actual_length for IN transfers.
The formats should be more similar. And given the availability of
usbmon, there doesn't seem to be any real need to dump the detailed
contents of an URB.
So my question is: For usbfs_snoop's purposes, what information should
we display? Maybe endpoint, direction, length or actual_length,
and timeout or status would be enough.
Any thoughts?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
_________________________________
This email has been ClamScanned !
www.LinuxLightHouse.com
--
jack craig
jackc@xxxxxxxxxxxxxxxxxxx
831-684-1375 (Office)
831-596-6924 (cell)
IM: jackcraigaptos (AIM)
_________________________________
This email has been ClamScanned !
www.LinuxLightHouse.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
