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