On 25/10/15(Sun) 12:10, Ludovic Coues wrote: > Usbdump is the result of my work during this summer of code. > It is a tool inspired by pcidump. It reads usb device descriptor and > print them with a bit of parsing. It aim to be a more friendly > alternative to lsusb.
I'd like to have an alternative to lsusb in base, simply to be able to debug USB-related problem without the need of installing a port. What do you mean by "more friendly"? Right now I have a hard time reading the output of the tool :) > There is two main difference with pcidump, boiling down to the nature of > the usb protocol. > First, an usb device does not provide a block of data like a pci > ddevice. It provide many piece of data, the descriptors. So the data > have to be fetched piece by piece. > Second, there is a few standard descriptors and many more specific to > certain class of device. In its current state, usbdump is far from > showing parsed data about most of these. > > In the future, I would like to add the ability show the data send by usb > device inside this tool, to make it more useful at troubleshooting. Something like tcpdump for USB? This would be really awesome. > As there there is nearly 3,000 lines, I will link to the sources. > It's available at http://home.jellycopter.net/usbdump . usbdump.tar.gz > is an archive of the directory, minus the archive. Full history > is hosted at http://home.jellycopter.net/repo/usbdump . > > I hope this will be useful. I believe it can be really useful. However I don't think we need both usbdevs(8) and usbdump(8) in base. Is your tool a drop-in replacement? Concerning the functionalities, I don't see the port hub status flags, this is really useful to be able to debug hub issues. Here's what lsusb prints: Hub Port Status: Port 1: 0000.0503 highspeed power enable connect Port 2: 0000.0500 highspeed power Regarding your code style(9) is not respected, simply running indent(1) should give you some hints ;) I would also recommend against mixing custom ioctl & USB request to fetch the information you need. I also think that mixing descriptor parsing and I/O is not a good idea. You should rather fetch all the data you need then parse it, rather than calling getstring() for example in the middle of your parser. This would allow to structure properly your code since USB data structure are defined by standard an independent from the kernel/OS interface. Finally I'd use more tables to map enums to strings and less printf() calls, this would also help changing the final output without digging in every function to find the corresponding printf() ;) I'd happily help if this was hosted in a VCS I can use (git or cvs). Maybe others would like to help too? What about putting this on github or similar in order to polish it? Martin
