Subject: Re: ancillary data alignment and binary backward compatibility
To: Chris G. Demetriou <email@example.com>
From: Jun-ichiro itojun Hagino <firstname.lastname@example.org>
Date: 03/09/2000 04:03:02
>> 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.
>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.