Re: question about mbuf intialization

[christos%astron.com@localhost (Christos Zoulas)]

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
>in m_gethdr.
>
>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;
>to m_gethdr?

Makes sense, but at the same time we should remove the superfluous zeroing
from the other places...

christos