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
