> > When I looked at this question last year I think I found that there
> > were few enough places in the kernel which used M_LEADINGSPACE, so
> > it should be fairly easy to check them. However, I think several
> > of the uses were in KAME code.
> The patch posted first by Luigi is safe because the patch doesn't
> change any semantics of M_LEADINGSPACE. I think it (and the patch)
> reasonbale that M_LEADINGSPACE returns 0 when the mbuf (cluster) is
> not writable and the real space when the mbuf (cluster) is writable.
So the M_LEADINGSPACE macro should probaly read:
#define M_LEADINGSPACE(m) \
(!M_WRITABLE(m) ? 0 : \
(m)->m_flags & M_EXT ? (m)->m_data - (m)->m_ext.ext_buf : \
(m)->m_flags & M_PKTHDR ? (m)->m_data - (m)->m_pktdat : \
(m)->m_data - (m)->m_dat)
and the comments for M_LEADINGSPACE and M_TRAILINGSPACE should note
the inconsistancy where M_LEADINGSPACE returns the number of writable
bytes and M_TRAILINGSPACE returns the number bytes, but doesn't indicate
if they are writable or not.
Maybe we should also provide M_{LEAD,TRAIL}INGSPACE_{R,W} macros
with consistant behaviour. The _R macros would be cheaper 'cos
they wouldn't have to check writability. These could be used in
the case where you already know the storage is writable.
(Here _R would mean "regardless" 'cos it's hard to imagine a
situation where you want to know how many readable bytes are outside
the valid data region in an mbuf ;-)
Bosko - what do you think of modifying M_LEADINGSPACE as shown
above and then providing these new macros? It would mean that we
can leave shared code alone, but where we want to optimise
M_LEADINGSPACE and M_TRAILINGSPACE we have the macros to do so.
David.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
