In some email I received from Atsushi Onoe, sie wrote:
> > 	Would there be any sense in defining a macro to be used to
> > 	initialise any 'fake mbuf', so we can centralise exactly
> > 	what needs to happen to them?
> 
> In order to do it, we should specify 'fake mbuf' and assign a mbuf type
> for it.  It would be:
> 	- the contents is volatile and cannot be refered after returning
> 	  the function.
> 	- the data buffer is read only,
> 	  # Should it be whole mbuf including mbuf header is read only?
> 	- cannot be freed

If it is "static struct mbuf ...", then you can return the mbuf.  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.

> After thinking these tricks,

They're not tricks, just restrictions...

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

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

Darren