Subject: Re: ancillary data alignment and binary backward compatibility
To: Jun-ichiro itojun Hagino <>
From: Chris G. Demetriou <>
List: tech-net
Date: 03/08/2000 10:41:52
Jun-ichiro itojun Hagino <> writes:
> >That's one possibility, probably the most sane.  (you don't want to
> >change the existing value for the sparc, because of binary
> >compatibility, and if sparc64's different, that's probably for a good reason.
> >> 	I'm not sure if this is possible for the kernel side to dance like
> >> 	this...
> >the kernel is just software.
> 	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.

Chris Demetriou - -
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.