Hi, I am one of the KAME members.
> The only problem I can see with this tack is that we might end up
> with M_LEADINGSPACE macro which does something different to the
> same macro in {Net,Open}BSD. I guess we should check what their
> macros do at the moment.
Right. And we will have a problem if someone changes the semantics of
M_LEADINGSPACE. The M_LEADINGSPACE macro of Net/OpenBSD does the same
as the current FreeBSD does, that is, returns 0 if M_EXT is set.
> 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.
But, I disagree the later proposal from Bosko that changes the meaning
of M_LEADINGSPACE. This leads more ifdefs in the shared code
(ex. KAME, maybe other cross-platform projects) and the code
complexity.
---
Keiichi SHIMA
IIJ Research Laboratory <[EMAIL PROTECTED]>
KAME Project <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
