This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/3] network: recvmsg and sendmsg standard compliance (BZ#16919)
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Zack Weinberg <zackw at panix dot com>, GNU C Library <libc-alpha at sourceware dot org>, Florian Weimer <fweimer at redhat dot com>
- Date: Thu, 9 Jun 2016 14:21:22 +0000
- Subject: Re: [PATCH 2/3] network: recvmsg and sendmsg standard compliance (BZ#16919)
- Authentication-results: sourceware.org; auth=none
- References: <1459175641-12520-1-git-send-email-adhemerval dot zanella at linaro dot org> <1459175641-12520-3-git-send-email-adhemerval dot zanella at linaro dot org> <a963950f-bb21-be79-bddd-8379b588378a at panix dot com> <5756D873 dot 1000701 at linaro dot org> <CAKCAbMgk7vtMFoXKJ45TwnFv7gqNesNk0AuSRHvg58XMSMaQTg at mail dot gmail dot com> <575886C8 dot 8000401 at linaro dot org> <5758DFF7 dot 5020800 at redhat dot com>
On Wed, 8 Jun 2016, Carlos O'Donell wrote:
> Regarding adding all linux syscalls, please see:
> https://sourceware.org/glibc/wiki/Consensus#WIP:_Kernel_syscalls_wrappers
> and the notes that Adhemerval provided.
Note that we have never managed to reach consensus on syscall wrappers.
However, I now disagree with the idea of a separate libinux-syscalls.so
library, or of only adding to libc.so those syscalls considered
appropriate for the OS-independent GNU API. I think that all non-obsolete
syscalls that can meaningfully be used outside of glibc in a glibc-using
program, even those extremely OS-specific or only likely to be of use to a
handful of programs on an OS, should have wrappers added to glibc, and
that we should not need to decide when adding them whether they are
appropriate for the OS-independent GNU API (although if there is consensus
for putting them in the OS-independent GNU API at the time they are added,
they should go there at that point - other functions might be added to the
OS-independent GNU API later).
We *do* still need to decide for such wrappers what the userspace types
are to use with them, what the prototype is, what header declares the
functions, and how errno and thread cancellation are handled. And we *do*
need documentation in the glibc manual for all such wrappers, and
testcases in the glibc testsuite (though some such tests may not be able
to do more than test that a call to the function compiles and links).
--
Joseph S. Myers
joseph@codesourcery.com