In some email I received from David Brownlee, sie wrote:
> On Fri, 27 Sep 2002, Darren Reed wrote:
> 
> > To each of 'these', I'm planning on adding this:
> >
> >                   /* XXX mbufs are not usually on the stack ... */
> >                   m.m_type = -1;
> >                   m.m_flags = 0;
> >
> > Before I *do* this, does anyone want to pipe up and say "bad boy, use
> > MGET() to get a _real_ mbuf for this" ?
> >
> > The issue here is that if bpf_mtap() and further into the BPF code
> > ever expect the pointer it gets passed to be a _real_ mbuf and tries
> > to do things with it, it could run into trouble.  The tradeoff is
> > speed.  I'm quite happy to put a large comment in bpf.c saying
> > something along the lines of "not all mbufs are equal and don't
> > ever try to alter the mbuf chain in here".
> 
> 	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?

That's two people who have suggested this, so maybe it makes sense.
How's look ?

#define	MBUFINIT(m)	{ (m)->m_type = -1; \
			  (m)->m_flags = 0; \
			  (m)->m_next = NULL; \
			  (m)->m_nextpkt = NULL; \
			  (m)->m_data = (m)->m_dat; \
			}

I'd like for m_type to be better initialised but to what?  If one was
to add a _real_ mbuf type, it should play well with mbtypes[] and I
_dont_ want it to do that.  Or is "#define MT_FAKE -1" ok ?

btw, while I think of it, pros & cons for changing mbuf type names from
#define's to enums ?

Darren