Hi Pete, > > Have you done any work on the binary interface for usbmon so far? I > > would be perfect if you can add something like that and then I work on > > the usbdump support for it. > > No, I haven't done anything tangible. I am not a big fan of abstract design, > also I do not have a good experience with binary formats or APIs. So, I keep > procrastinating with this. I was going to rack your brain for ideas, frankly. > Also, there's some work to be done elsewhere (I want to have controls and > SCSI commands decoded, for example).
basically this is what usbdump is all about. Decoding of higher level stuff like USB storage, Bluetooth etc. In general I don't care if it is text or binary, but the current text format is limited when it comes to the bulk data. And I don't see any need to convert it first to text and then let usbdump parse it back into a binary representation. The only thing we should try is to export all needed information to usbdump and then let it do the rest. > The only thing I'll insist on is that the fields had a fixed size, > and not "int" or "long". OK, maybe not the only thing, but we'll see. Exactly. > > Since you are using the URB pointer and the kernel timestamp, how do we > > deal with the 32-bit userland vs. 64-bit kernel thing? > > It is not an issue in text formats, as long as the userland does not > make assumptions about the word lengths. An application reads them as > text words. In ideal world, it makes no assumption about their lengths. > In real world, applications allocate buffers for these words, and > report errors in case of overflow. So, this is one of advantages of > a text format. Once the application starts to convert back to binary, > it may hit word size limits and overflows. But if you're willing to > declare all fields "long" in Java and "long long" in C, it's all right. > If it's vital, I can make timestamps quasi-non-wrapping, to help with > ordering of events, for instance. Personally I would like to have uint32_t timestamps. However I don't really know if that is possible and/or if it makes sense. > The real issue with tags is fundamentally very annoying and is present > in both binary and text formats. In case of Ethernet, all packets are > independent, but here we have to establish some identify in order to > group events. I still think about some sort of in-kernel tracking. > Currently, usbmon is stateless. I had a prototype which tracked URBs, > which could conceivably give each transfer a sequential number, but > it was fragile and complex. Actually I think the grouping of submission and callback should be done fully inside the usbdump utility, but as you said we need somekind of id tag to correctly group them. What do you think of numbering the URBs and use this number instead of the pointer. For example use an uint32_t for it and then we only must make sure that no "in-fly" URB gets the same number. Regards Marcel ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
