Jun-ichiro itojun Hagino <itojun@iijlab.net> 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.



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.