>> >>    #define CMSG_NXTHDR(mhdr, cmsg) \
>> >>        ( ((cmsg) == NULL) ? CMSG_FIRSTHDR(mhdr) : \
>> >>          (((u_char *)(cmsg) + ALIGN((cmsg)->cmsg_len) \
>> >>                             + ALIGN(sizeof(struct cmsghdr)) > \
>> >>            (u_char *)((mhdr)->msg_control) + (mhdr)->msg_controllen) ? \
>> >>           (struct cmsghdr *)NULL : \
>> >>           (struct cmsghdr *)((u_char *)(cmsg) + ALIGN((cmsg)->cmsg_len))) )
>> >>   The macro ALIGN(), which is implementation dependent, rounds its
>> >>   argument up to the next even multiple of whatever alignment is
>> >>   required (probably a multiple of 4 or 8 bytes).
>Obviously, they're talking about a general 'ALIGN' macro, which may or
>may not be the same as our specific alignment function.  our specific
>alignment function.
>Note that it says "next even multiple of whatever alignment is
>required."
>
>This is different than the alignment provided by our ALIGN macro and
>ALIGNBYTES value.  They align to the maximum possible necessary
>alignment, not the actual alignment needed.

	I'm very convinced that ALIGNBYTES is correct here.  We can't foresee
	what kind of structs are put into ancillary message.  If we use
	something smaller than ALIGNBYTES, every time we pass new struct via
	ancillary message (which exceeds the alignment defined) we need to
	change CMSG_ALIGN and we'll have binary compatibility issue.

	So, at least need to bump from 3 to ALIGNBYTES.
	- How to bump
	- how to determine ALIGNBYTES (statically by header of hw.alignbytes
	  sysctl MIB)
		current tree uses hw.alignbytes
	is still not 100% decided...

itojun