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 11:38:23
Jun-ichiro itojun Hagino <email@example.com> writes:
> Before sometime y2k, ancillary message alignment was not conformant
> to Posix.1g (it was aligned to 3, not ALIGNBYTES).
Perhaps I missed the discussion of this, but what's the exact wording
of .1g in this regard? (Does it specifically say "ALIGNBYTES" (doubt
it), mention system alignment for the relevant data types, strictest
system alignment or what?
ALIGNBYTES is '7' on sparc because it aligns the "strictest data
type". If i recall correctly, on the sparc, the only native data type
that needs to be aligned to 8-byte boundaries is "double," and it was
made that way to accomodate that. (long longs may also need to be
aligned, i'm not sure about that. looking at gcc, this may now be
true, though i'm not convinced it was originally.) i may be
> 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.
That's not true. You could, for instance, change the syscall numbers
of the syscalls that use the data. This has been done in the past
when features in structures, or their sizes or alignments, have been
basically, what you're saying here is, you didn't do the work of
making the bits compatible, and you don't think it's necessary to do
Whether that is or isn't the right decision, I don't know, and i'm not
going to beat the horse to a pulp...
Chris Demetriou - firstname.lastname@example.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.