In some email I received from Atsushi Onoe, sie wrote:
[...]
> > The only
> > thing, in the above list that I would hold true is the last - you cannot
> > free them.  This means you can't safely use things like m_pullup(), etc.
> 
> The 'etc' is what I hate.  There are number of mbuf functions and macros
> we can't use for fake mbuf.  It is hard for us to check against it.

Well, currently, there is no such usage in BPF and you could correctly
argue there never should be.

The question then is does this encourage similar use elsewhere and is
that a good/bad idea ?

> > > I'd rather prefer adding new API to bpf,
> > > such as,
> > > 	void bpf_mtap2(caddr_t bpf, caddr_t hdr, int hdrlen, struct mbuf *m);
> > > # sorry that I don't have ability in naming.
> > 
> > I'm not sure I like this idea.  Or maybe I do.  There is no explicit
> > kernel-only interface for BPF tap, at present, so maybe this could be
> > it?
> 
> I'm not sure what you mean here.  From my understanding, all the bpf tap
> interfaces are used kernel-only.  These definitions are included within
> #ifdef _KERNEL in net/bpf.h.

Ack!  For some reason I thought the stuff in bpf.c was compiled into
libpcap too.  I checked and its not - maybe I was thinking of
bpf_filter.c and expected the same to apply to bpf.c.

So given that bpf_mtap() is already an explicit interface for mbufs,
why do we need bpf_mtap2() ?  The prototype you gave did not seem to
suggest it was a big advantage to have.

I could maybe see the point in having a bpf_dlt_mtap() that had
the 'common code' from all of the DLT_NULL intraface calls of
bpf_mtap() in it.

> > > Is there any place other than bpf where 'fake mbuf' is used?
> > 
> > You might use them in userland programs if you want to build test code
> > for kernel stuff.  I can imagine there might be times you want to use
> > "fake mbufs".
> 
> In order to test code for kernel, I'll implement m_get/MGET anyway and
> initializer for mbuf will be used only there.  I think it is not reasonable
> to introduce initializer only for the purpose.

My problem with using MGET here is it is a code path that _is_ speed
sensitive if you're buliding something like an IDS on top of NetBSD.

This is a change that would make NetBSD slower than others.

Darren