[RFC] USBdump patches

[Hans Petter Selasky]

On Wednesday 24 November 2010 01:18:32 Weongyo Jeong wrote:
> On Tue, Nov 23, 2010 at 06:52:36PM -0500, Jung-uk Kim wrote:
> > On Tuesday 23 November 2010 06:31 pm, Jung-uk Kim wrote:
> > > [CC sanitized]
> > > 
> > > On Tuesday 23 November 2010 06:01 pm, Hans Petter Selasky wrote:
> > > > Dear Weongyo,
> > > > 
> > > > > NACK.  You already could recognize that the patch is quite big
> > > > > and multiple patches are mixed into one.  Please separate into
> > > > > smallest pieces then send freebsd-usb@ again.  I don't want to
> > > > > do a jumbo jump.
> > 
> > Technically, I don't like the copy-and-pasted code from bpf.c and
> > bpf_filter.c.  Was it really necessary?  Is the dump file in PCAP
> > format?
> > 
> > Please enlighten me if I missed something.
> 
> The following paragraph is extracted from email I sent to rwatson@
> because he also asked same question to me.  And I added CC to
> freebsd-usb@ to share my story with other developers who might think
> similar.

Hi,

> 
>   Hello Roberts,
> 
>   I understand what you're worry and agree with you that if I could remove
>   this duplication it'd be best one.  I think it could be happen enough
>   later if we could reach the consensus.
> 
>   The biggest confusions I encountered during implementing? (porting) it
>   for USB packet filter were as follows.  Please let me know if there are
>   something I missed:
> 
>    - BPF was normally for ethernet frames (most operations were based on
>      mbuf including the machine filter and there were a lot of
>      assumptions the input buffer is mbuf type.  For example, handling
>      BPF_LD|BPF_W|BPF_ABS).  However the USB packet isn't like mbuf style
>      that it's just a linear buffer.  So the most important code or
>      assumption wasn't compatible.

The equivalent to mbufs in USB terms are page caches. Where mbuf references 
are used pc's should be used instead.

>    - Just making the patch for BPF code, it looked like a trick or a hack
>      to me because I couldn't define what BPF should be.

I think that to be really useful the BPF code needs some additional 
information through additional misc. instructions to orientate about the data 
it is getting from USB. For example the frame number, state for control 
transfers and endpoint number.

>    - I could not define BPF exactly myself that what BPF should cover.
>      I agreed with that BPF is for ethernet packet filtering but could
>      not make sure myself that BPF could cover USB packets.

I think this is a good idea, but it needs some adoption. For example not all 
USB packets have a fixed header. But in case of mass storage there is a fixed 
header where we could add trigger fields.

> Please tell me your opinion if you guys have better approach.

--HPS