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

Yes, it is exactly what I'd like to discuss.  Defining mbuf initializer
in common code (e.g. sys/mbuf.h) looks encourage to use fake mbuf for me.
If you are proposing such initializer macro to put in net/bpf.h, I can
agree except for the name, which should be prefixed with BPF_.

> 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.

It just hide any possible hacks within bpf.  Within bpf code, you can
safely use fake mbuf or anything useful since you know that the caller
of the bpf module only refer the limited members of mbufs.

If you try to expose such behaviour out of bpf module, the interface
should be well defined to do the right thing, IMO.

> 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.

It could be a possible solution, though I'm not sure the exact definition
also useful for ieee1394subr.c and some wireless interface such as wi.c.

The proposed bpf_mtap2() is quite simple and covers most of common cases.
Adding some lower linklayer header 

> > > > 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".

> 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.

I don't object your use of fake mbuf in your userland programs.
But it is a separate issue discussed here.

Atsushi Onoe