Re: + preadv-pwritev-add-preadv-and-pwritev-system-calls.patch added to -mm tree

["H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>]

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.)

What we *SHOULDN'T DO* is hand-craft the ABI of every system call to
avoid the rules we happen to have already set for ourselves.  If the
rules are too inflexible, they should be sanitized, not worked around.

The sheer number of system calls with weird exceptions to the ABI is a
total mess, and for absolutely no good reason.  All it means is an
exception which last forever, because no amount of automation in the
world can fix it once it is in.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html