In message <[EMAIL PROTECTED]>, David Malone writes:
>
>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)
Yes, I think this is cleaner than the version that was just committed
to -stable, and it could have been committed to -current and MFC'd
in the normal way without changes. I really doubt that it is worth
splitting up M_WRITABLE just to marginally optimise M_LEADINGSPACE.
>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.
This optimisation seems the only reason why it might make sense to
change the current semantics of M_LEADINGSPACE to ignore writeability,
and I'm not sure that even this is worthwhile. While the word
'space' does not necessarily imply 'writable space', why would
anything ask for the leading or trailing space if writing to it
was not being considered?
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
