On Tue, 27 Feb 2007 13:47:41 -0500, "Jon Smirl" <[EMAIL PROTECTED]> wrote:
> This is the structure being returned: >[...] You are confusing the usbmon's API with the "packet format" which Paolo manufactured for Wireshark's internal consumption. In his case, he has to present some kind of stream of packets. In my case, the model is that of tapping into internal API. Think about 'E' events, for example. There may be more types in the future (e.g. 'U' for unlinks, if we decide that we want those). Naturally, an attempt to stuff the usbmon's output into the packet paradigm leaves some lint. > If that is the case then the flag_setup field is > redundant with the type field and can be eliminated. I would then make > the setup[8] presence variable depending on the packet type. And would I want to do that? Currently, an application can determine if a setup packet is present by examining the flag. Why waste the code on this if kernel has already examined all necessary fields? > The protocol can be further compressed by not including these fields: > xfer_type, epnum, devnum, busnum in completion/error packets. I'm not interested in variable length structures if the benefit is just a couple of bytes. If Paolo wants to waste cycles on compressing this internally only to let dissectors to waste more cycles on parsing, I am not stopping him. But this is certainly not anything I plan on doing. Greetings, -- Pete ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
