Subject: Re: ancillary data alignment and binary backward compatibility
To: Chris G. Demetriou <cgd@netbsd.org>
From: None <itojun@iijlab.net>
List: tech-net
Date: 03/09/2000 06:19:21
>> 	Before sometime y2k, ancillary message alignment was not conformant
>> 	to Posix.1g (it was aligned to 3, not ALIGNBYTES).
>Perhaps I missed the discussion of this, but what's the exact wording
>of .1g in this regard?  (Does it specifically say "ALIGNBYTES" (doubt
>it), mention system alignment for the relevant data types, strictest
>system alignment or what?

	I don't have Posix.1g in my hand, but I have RFC2292 which should be
	saying the same thing (page 21).

>>   One possible implementation could be:
>>
>>    #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).


>> 	the kernel have no way to detect what the userland code thinks about
>> 	ancillary data alignment, so kernel cannot really adapt to the
>> 	alignment compiled into userland code.
>That's not true.  You could, for instance, change the syscall numbers
>of the syscalls that use the data.  This has been done in the past
>when features in structures, or their sizes or alignments, have been
>changed.
>
>basically, what you're saying here is, you didn't do the work of
>making the bits compatible, and you don't think it's necessary to do
>it.
>
>Whether that is or isn't the right decision, I don't know, and i'm not
>going to beat the horse to a pulp...

	hmm, it seems I was wrong about the choice... does the following
	look like the right way?
	- change syscall # of sendmsg and recvmsg.  
	- add ALIGNBYTES to syscall argument for sendmsg/recvmsg.  it will be
	  added by syscall library (it means that, at least, libc and
	  user code must agree about ALIGNBYTES).
	  for old syscall #, ALIGNBYTES arg will be hardcoded into 3 at
	  kernel entry point.
	- propagate alignment constraint value given from the userland into all
	  over the places like sys/netinet6, sys/netiso or sys/netccitt.
	there's some incompatibility window for several weeks (with my
	change that uses hw.alignbytes).

itojun