Subject: Re: ancillary data alignment and binary backward compatibility
To: Jun-ichiro itojun Hagino <email@example.com>
From: Chris G. Demetriou <firstname.lastname@example.org>
Date: 03/08/2000 10:41:52
Jun-ichiro itojun Hagino <email@example.com> 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 - firstname.lastname@example.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.