On Tue, 2007-05-08 at 10:30 -0700, Pete Zaitcev wrote:
> On Tue, 08 May 2007 08:48:26 +0200, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> > That will be a better solution, but most unfortunately it does not fit
> > easily with libpcap design: libpcap is designed to provide a whole frame
> > in a conti
On Tue, 08 May 2007 08:48:26 +0200, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-05-07 at 11:19 -0700, Pete Zaitcev wrote:
> > I thought we agreed not to do that and only provide the URB data
> > for zero copy.
>
> That will be a better solution, but most unfortunately it does not fit
>
Hello,
On Mon, 2007-05-07 at 11:19 -0700, Pete Zaitcev wrote:
> I thought we agreed not to do that and only provide the URB data
> for zero copy.
That will be a better solution, but most unfortunately it does not fit
easily with libpcap design: libpcap is designed to provide a whole frame
in a c
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 r
On Fri, 2007-05-04 at 13:08 -0700, Pete Zaitcev wrote:
> I still do not understand why it is important to limit the size
> this way. I see that your patch is shorter than mine, which is good.
> But it seems to create an excessively complicated bunch of unions.
> I cannot comprehend the logic which
On Fri, 04 May 2007 10:25:38 +0200, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> I tried to address the issues in my latest patch for implementing the
> extended binary API, while keeping the header size to 48 bytes. This is
> the result.
I still do not understand why it is important to limit the si
Hello,
I tried to address the issues in my latest patch for implementing the
extended binary API, while keeping the header size to 48 bytes. This is
the result.
All the data fields recognized by usbmon are now in host byte order. The
'xfer_flags' field is now present also for submit events (reus
