On Fri, Oct 26, 2001 at 01:10:34PM +0100, David Malone wrote:
> 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.
I already stated what I thought about it: it's wrong for reasons
mentionned in previous Emails. It means that we will be adding support
for a broken macro, not to mention enlarging the macro, which is bad
especially for code that is actually using it properly.
> David.
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
