Principles for syscall wrappers, again

[Joseph Myers]

On Fri, 22 May 2015, Adhemerval Zanella wrote:

> I think your points are reasonable and I see no impose arguments
> about not use it the guideline for future wrappers.  How should
> we document this principles for future references: a documentation
> file in source code or just wiki entry in sourceware.org?

My assumption is that if we get consensus then it would be documented on 
the wiki.

> Also, for arch-specific syscalls, should we apply to same principles
> or may the maintainer be able to discuss more specific points (for
> instance, the usage is limited to a set of programs/libraries)?

I excluded arch-specific syscalls from my proposed principles since (a) 
Mike's objection in 
<https://sourceware.org/ml/libc-alpha/2014-10/msg00591.html> said 
"especially for arch-specific syscalls" and (b) I don't think 
arch-specific syscalls are the main problem with glibc's syscall API 
having been frozen since Linux 3.2 / glibc 2.15.

My proposed principles are primarily principles for what to add rather 
than not what to add.  If you wish to add something not covered by those 
principles, you can always seek consensus that the given syscall should be 
added despite not meeting the criteria I suggest (or indeed propose 
supplementary criteria, such that wrappers for new syscalls should be 
added if they meet either set of criteria).

What I hope with my principles is that for *most* cases, the discussion 
doesn't need to be about whether to add a binding at all, but rather about 
such things as what header the declaration goes in and all the ordinary 
things checked in any patch review for a new API.  That is, it's a 
shortcut to consensus for "should we add this API at all?", to avoid the 
same issues being rehashed every time, much like other shortcuts to 
consensus we have (e.g. that certain patches can be committed without 
prior review).

-- 
Joseph S. Myers
joseph@codesourcery.com