Subject: Re: CVS commit: syssrc/sys/net
To: Atsushi Onoe <email@example.com>
From: Darren Reed <firstname.lastname@example.org>
Date: 09/29/2002 17:51:40
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
> 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