[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: question about mbuf intialization
In article <546B8CEC-0675-463F-B5C8-6A0FD5541B83%bbn.com@localhost>,
Beverly Schwartz <bschwart%bbn.com@localhost> wrote:
>In function m_get, all fields in struct m_hdr are initialized except
>mh_paddr (m_paddr) and mh_len (m_len). m_paddr is initialized in a
>constructor provided to the pool, so that also gets initialized.
>In function m_gethdr, all fields in struct pkthdr are initialized
>expcept segsz and len. segsz is there for TCP, so cannot be initialized
>I am wondering why m_len and m_pkthdr.len are not initialized.
>The man page for mbuf does not indicate that the user needs to set these
>fields after calling m_get or m_gethdr. (The macros calling these
>functions don't set the length fields either.)
>As the NetBSD kernel stands now, all protocol use of mbuf's takes care
>of setting the length. But who is to say there may not be a protocol in
>the future that depends on the lengths being initialized to 0?
>The functions m_copydata and m_copyback rely on these fields. If a
>protocol decides to use these functions to load data rather than using
>mtod and writing directly to the mbuf data bytes, without
>initialization, these functions will have unpredictable behavior.
>I am using rump to test some kernel code which heavily relies on mbuf's.
>In that environment, I am calling mbuf functions to get mbufs and
>manually filling the mbufs using m_copyback. I can initialize m_len and
>m_pkthdr.len to 0, but this is a pain, and I have to remember to do this
>for each mbuf I get.
>Any reason why we can't add
> m->m_len = 0;
>to m_get, and
> m->m_pkthdr.len = 0;
Makes sense, but at the same time we should remove the superfluous zeroing
from the other places...
Main Index |
Thread Index |