Principles for syscall wrappers, again

[Joseph Myers]

On Tue, 26 May 2015, Rich Felker wrote:

> > Thus, it seems to me we should explicitly discuss the GNU API we want to
> > expose for each syscall's functionality that we want to offer, and not
> > just expose syscalls interfaces as-is by default.
> 
> I think this is gratuitous NIH'ing and a disservice to applications.
> Code which wants to use the futex API is already doing so via
> syscall() with the existing API, and is most easily updated to use
> futex(). Your proposed API is not any more general or easier to
> provide on NaCl or elsewhere; the existing API can easily be provided
> because it's equivalent.

Agreed.  As I said in 
<https://sourceware.org/ml/libc-alpha/2015-05/msg00764.html>, I think the 
API details to discuss are things such as the userspace types and the 
header with the declaration, not any more substantial rearrangement of the 
API - treating Linux as an API source like BSD and SysV, except for API 
details outside the scope of what the kernel defines.

-- 
Joseph S. Myers
joseph@codesourcery.com