Subject: Re: CVS commit: syssrc/sys/net
To: None <firstname.lastname@example.org>
From: Atsushi Onoe <email@example.com>
Date: 09/30/2002 08:14:42
> 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
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.