> If it is "static struct mbuf ...", then you can return the mbuf.

But it introduces new restrictions
	- only one fake mbuf at a time available
	- you cannot sleep while using fake mbuf
	- if you want to use fake mbuf at interrupt level (like bpf),
	  you have to use set spl while using 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.

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.

> > After thinking these tricks,
> 
> They're not tricks, just restrictions...

restrictions introduced by tricks, IMHO.

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

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

Atsushi Onoe