Date: Sun, 15 Oct 2000 20:18:24 +0100
From: David Malone <dwmalone@maths.tcd.ie>
To: freebsd-net@freebsd.org
Subject: M_{LEADING,TRAILING}SPACE definitions.
Message-ID: <200010152018.aa65610@salmon.maths.tcd.ie>
next in thread | raw e-mail | index | archive | help
I'm just looking at implimenting writeable external storage management
for mbufs. Most parts of the kernel are quite conservative about
writing to anything that isn't a plain mbuf, and this work should
allow it more freedom.
Important in this are the M_LEADINGSPACE and M_TRAILINGSPACE macros.
#define M_LEADINGSPACE(m) \
((m)->m_flags & M_EXT ? \
/* (m)->m_data - (m)->m_ext.ext_buf */ 0 : \
(m)->m_flags & M_PKTHDR ? (m)->m_data - (m)->m_pktdat : \
(m)->m_data - (m)->m_dat)
#define M_TRAILINGSPACE(m) \
((m)->m_flags & M_EXT ? (m)->m_ext.ext_buf + \
(m)->m_ext.ext_size - ((m)->m_data + (m)->m_len) : \
&(m)->m_dat[MLEN] - ((m)->m_data + (m)->m_len))
Note the difference - M_LEADINGSPACE always returns 0 for external
storage - M_TRAILINGSPACE will always return the amount of space
at the end of the buffer, even if it is unwritable. They have both
been this way since version 1.1 of mbuf.h.
Does anyone know why they are defined in this inconsistant way? I'd
like to make them consistant and either have:
1) Both return 0 if the storage isn't writable.
2) Have both return the amount of space, but make the kernel check
M_WRITABLE(m) before writing to it.
M_LEADINGSPACE is only used about 16 times in the kernel and it's
users tend to assume that the space in question will be writable.
M_TRAILINGSPACE is used about 60 times, most consumers seem to
ensure the writeability themselves. This suggests I should go for
option 2 and then check the places where M_LEADINGSPACE is called.
I could have an option (3) where the M_LEADINGSPACE behaves in a
different way to M_TRAILINGSPACE, and have the former check
M_WRITEABLE before returning.
David.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200010152018.aa65610>