itojun@iijlab.net writes:
> 	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).

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 aware of the old control msg needs for alignment: 4 bytes.  (they
were all 4-byte ints, which in our worst case need to be 4-byte
aligned.)

As far as I can tell, none of the structures in RFC 2292 will have
alignment needs > 4 bytes (since at most, they seem to use 4-byte
fields), unless they're being used on architectures which happen to
require 8 byte structure alignment (of which there are none that i'm
aware; some normal ABIs for archs we support require 4-byte alignment
for structs -- e.g. arm, which we've broken -- but none require 8 that
i'm aware of).

I may be missing something here, but ...
For new ports, going forward, using 'ALIGNBYTES' might be a good thing
to do, but at this point, i'm not sure why changing the existing
definition from 3 -> ALIGNBYTES is necessary at all!



> 	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.

Uh, no, that's not the right thing to do, if you're going to do it
that way.

You cahnge the syscall # of sendmsg and recvmsg, and say that the data
returned by them will always be aligned with ALIGNBYTES for the
particular MACHINE_ARCH.

in their implementation, you basically add one function call level of
indirection, i.e. have a 'sendmsg1()' or similar that gets sendmsg's
args plus the alignment value: ALIGNBYTES for the new syscalls, 3 for
the old.

The alignment should _not_ be passed across the syscall interface.


But again, i'm not even sure why this is necessary at all right now,
based on the stuff that i've read!


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.