On Fri, 04 May 2007 22:30:40 +0200, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> The usbmon header is provided 'as is' to the application layer via a > specific libpcap data link type (to take advantage of the 'zero copy' > memory mapped access). A change to the header size (or binary layout) > will require a different data-link-type and will make new libpcap trace > incompatible with old ones. I thought we agreed not to do that and only provide the URB data for zero copy. The amount of 64 bytes is miniscule and copying of it can easily be offset by efficient coding. Data copying can easily show in profiles though, it's where the bulk of network traffic and firmware uploads happen... > My goal is to minimize the amount of rough edges on both kernel and user > space side, and I thought that keeping the interface compatible was the > right way to do that... I'm afraid that adding branches could eat all savings from keeping to the 48 byte format headers. I'm wondering if we're talking about nothing here though. The old binary header delivered the bus number already, so you may as well stick to it until someone really wants to see ISO descriptors... Unfortunately, my patch puts them into data area, so they screw your data if I spring a kernel update on you. Your patch is clearly better in that. To prevent it, I'll think once again about borrowing the 'P' message from your patch. -- Pete ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
