On Tue, Feb 03, 2009 at 09:29:24AM -0800, H. Peter Anvin wrote: > Russell King wrote: > >> > >> All in all, I think it is WRONG to make sane architectures suffer for > >> what broken architectures have to do, and we should implement this the > >> sane way without any shuffling, splitting, or other braindamage. > > > > Disagree. What is better: having _one_ _common_ argument order in the > > syscall interface, or having architectures end up doing their own thing? > > > > Think about your strace argument - you're effectively requiring strace > > to know that on architecture X, the syscall argument order is X1, but > > on architecture Y, that same syscall has argument order Y1, and maybe > > architecture Z, it's again a different order Z1. > > > > That _adds_ complexity to strace - rather than having one ordering to > > deal with for a syscall, it now has three different random orders. > > > > That's completely insane. With one _common_ ordering, at least strace > > has the possibility of cleanly sorting it out. > > > > What we *SHOULD* be doing is to *HAVE ABIS RULE AND STICK TO THEM*. > Which is that on architectures that need a padding register, we add the > padding register on those architectures, and if they need stubs, then we > add stubs -- preferrably by automation (c.f. my automation scripts for > doing exactly that.) This is an overly simplified view of things. There exist syscalls where it's not just a matter of padding, but instead where the chosen argument order interacts with the ABI padding requirements to produce something which the syscall interface can't handle. There are two solutions to that: reorder the syscall arguments or split them up into 32-bit high/low quantities. I'm thinking there of the silly fadvise64_64 syscall, where ARM was forced into having a different argument ordering from everything else through zero discussion. So, what would your scripts do with the fadvise64_64 syscall on an architecture requiring natural alignment of the 64-bit args in 32-bit regs? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
