I believe it covers all cases *relevant for this particular situation* (unlike, say, MIPS) and that any deviation is a bug which can and should be fixed.
"David Daney" <dda...@caviumnetworks.com> wrote: >On 12/30/2010 12:12 PM, H. Peter Anvin wrote: >> On 12/30/2010 11:34 AM, David Daney wrote: >>> >>> My suggestion: Since people already spend a great deal of effort >>> maintaining the existing i386 compatible Linux syscall >infrastructure, >>> make your new 32-bit x86-64 Linux syscall ABI identical to the >existing >>> i386 syscall ABI. This means that the psABI must use the same size >and >>> alignment rules for in-memory structures as the i386 does. >>> >> >> No, it doesn't. It just means it need to do so *for the types used >by >> the kernel*. The kernel uses types like __u64, which would indeed >have >> to be declared aligned(4). >> > >Some legacy interfaces don't use fixed width types. There almost >certainly are some ioctls that don't use your fancy __u64. > >Then there are things like ppoll() that take a pointer to: > > struct timespec { > long tv_sec; /* seconds */ > long tv_nsec; /* nanoseconds */ > }; > >There are no fields in there that are controlled by __u64 either. >Admittedly this case might not differ between the two 32-bit ABIs, but >it shows that __u64/__u32 are not universally used in the Linux syscall > >ABIs. > >If you are happy with potential memory layout differences between the >two 32-bit ABIs, then don't specify that they are the same. But don't >claim that use of __u64/__u32 covers all cases. > >David Daney -- Sent from my mobile phone. Please pardon any lack of formatting.