On 12/30/2010 12:28 PM, H.J. Lu wrote:
On Thu, Dec 30, 2010 at 12:27 PM, 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.
We can put a syscall wrapper to translate it.
Of course you can.
But you are starting with a blank slate, you should be asking yourself
why you would want to.
What is your objective here? Is it:
1) Fastest time to a relatively bug free useful system?
or
2) Purity of ABI design?
What would the performance penalty be for identical structure layout
between the two 32-bit ABIs?
Really I don't care one way or the other. The necessity of syscall
wrappers is actually probably beneficial to me. It will create a
greater future employment demand for people with the necessary skills to
write them.
David Daney
