This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Principles for syscall wrappers, again
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: <libc-alpha at sourceware dot org>
- Date: Thu, 28 May 2015 16:51:28 +0000
- Subject: Re: Principles for syscall wrappers, again
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1505182114090 dot 16300 at digraph dot polyomino dot org dot uk> <20150519000918 dot GB17573 at brightrain dot aerifal dot cx> <1432630525 dot 3077 dot 36 dot camel at triegel dot csb> <20150526151000 dot GA17573 at brightrain dot aerifal dot cx>
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