>> 	we end up having two code for sys/netinet6 or sys/kern/uipc_socket.c,
>> 	is it really something what we want to do?
>If that's the case, then i think it might be reasonable to say that
>the kernel code is badly implemented.  If this padding, in the kernel,
>is something that needs to be parameterized, that might be a sensible
>thing to do.
>
>Changing the rules on user-land, or even changing the going-forward
>requirements for programs to interoperate like this, is only trouble
>and will only cause compatibility problems.

	hmm...

>If the claim is that sparc64 will be able to run sparc(32) binaries, I
>should be able to take a sparc(32) binary from two years ago and run
>it as long as i've got the right compatibility options enabled (just
>as i should be able to take a sparc(32) binary from 2 years ago -- or
>whatever arbitrary time ago -- and run it on the -current sparc
>kernel, if i've got the right compatibility options enabled).
>
>With a change like you describe, that won't be possible will it?  And,
>if not, the emulation's broken.

	I tend to agree that we need to be able to run 2-years-old sparc32
	binary on the latest kernel, but I don't think it's really possible
	to support old userland code in this case.

	Before sometime y2k, ancillary message alignment was not conformant
	to Posix.1g (it was aligned to 3, not ALIGNBYTES).
	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.

	to break it down a bit:
	- CMSG_xx were defined wrongly in the past (biased to i386/whatever)
	- CMSG_xx are macros, which compiles certain alignment constraint
	  into binaries.  there's no way to know actual alignment constraint
	  by looking at binaries.
	- old binaries will not inform the kernel of their idea about ancillary
	  data alignment. (therefore, there's no way to help old binaries)

	the current code allows userland code to be friendly with the alignment
	constraint the kernel imposes.  this fixes the second one at least.

itojun