>> 	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...
>ALIGNBYTES is something that can't change for a given MACHINE_ARCH (or
>shouldn't, unless there's a big flag day for that port).
>There's no reason to do this using a sysctl.  it just adds overhead.

	I thought again about it, and I think I'm really stuck.
	What level of binary backward compatibility do we need to provide
	in such situation?

	Note that we have similar issue in routing socket data alignment.
	(see macro ROUNDUP in sys/net/rtsock.c)

itojun


ALIGNBYTES setting from the spec:
- let us assume that the CPU native alignment is ALIGNBYTES_KERNEL.
- old binaries hardcode ancillary data alignment of "sizeof(long) - 1".
- from POSIX.1g spec, ancillary data alignment should be ALIGNBYTES_KERNEL.
- for compat_netbsd32 situation, userland code may be compiled with different
  ALIGNBYTES from ALIGNBYTES_KERNEL (let us call ALIGNBYTES_COMPAT).

ways to cope with ancillary data alignment:
(1) Rewrite data stream in socke tdata buffer to change ancillary data
    alignment.  This must rewrite those in sys_sendmsg(), sendit(), or
    somewhere similar.  We can't do it in, for example, sys/netinet6/*.
(2) Make userland code adapt to the kernel alignment constraint
    (ALIGNBYTES_KERNEL).  This is the code in the tree.
(3) cmsg_{level,type} are typed as "int".  they can be of different size
    for compat_netbsd32 situation.  We may need to modify data stream in
    socket for this, like (1).

problem with (1) and (3):
Even though (1) and (3) suggest rewrite of datastream in socket data buffer,
it is not very trivial.  We are not very sure if data stream in "control"
data stream is formatted/aligned properly to meet ALIGNBYTES_KERNEL, or
userland alignment.  What kind of error should we raise?  What kind of
behavior we should present if control data stream is truncated/insufficient?
What happens if they gets out of sync?

- It is trivial to support binaries with ALIGNBYTES_KERNEL (= userland
  and the kernel agrees about ancillary data alignment).
- For supporting old binaries (binaries with sizeof(long) - 1),
  we need to do (1) with syscall renumbering, for data alignment.
  With old syscall # we'd rewrite alignment from/to sizeof(long) - 1
  to/from ALIGNBYTES_KERNEL.
- For supporting binaries with ALIGNBYTES_COMPAT (compat_netbsd32),
  we need to do either (1)+(3), or (2)+(3).  We need (3) Since
  cmsg_{level,type} are typed as "int" and sizeof(int) can be different
  between userland and the kernel.