This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Consensus on adding kernel syscall wrappers.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Andreas Schwab <schwab at suse dot de>, Siddhesh Poyarekar <siddhesh at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>, Maxim Kuvyrkov <maxim at kugelworks dot com>, "Ryan S. Arnold" <ryan dot arnold at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>
- Date: Thu, 23 Oct 2014 21:10:39 -0400
- Subject: Consensus on adding kernel syscall wrappers.
- Authentication-results: sourceware.org; auth=none
I've drafted some consensus notes regarding the addition of kernel
syscall wrappers. These notes are based on Joseph Myers's comments.
Please read them and comment. We are looking for consensus on the
addition of linux kernel syscall wrappers to glibc.
There is still work to be done in reviewing the list of missing
syscall wrappers and applying this consensus to them and carrying
out the actual work.
https://sourceware.org/glibc/wiki/Consensus#WIP:_Kernel_syscalls_wrappers
~~~
3. WIP: Kernel syscalls wrappers
This consensus entry is a work in progress:
* If a syscall is obsoleted by another syscall (or otherwise considered
obsolete), there is no need to add a wrapper to glibc.
* If a syscall cannot meaningfully be used behind glibc's back, or is
not useful in the glibc context except for in the ways in which it is
used by glibc, but can only be used directly by glibc, there is no
need to add a wrapper to glibc (this probably applies to set_thread_area,
for example).
* If there's a glibc function that's not quite a direct wrapper of the
syscall but provides all the functionality of it that can usefully be
used in a program using glibc, there is no need to add a wrapper to glibc.
* Wrappers to syscalls should be added by default (both for syscalls not
used in glibc, and for cases such as futex where the syscall is used in
glibc but can usefully be used directly as well) unless there is a clear
reason not to. This includes for architecture-specific syscalls.
* If a wrapper is provided, there should also be a header with corresponding
declarations (that either provides any relevant constants / structures or
includes appropriate kernel neaders providing them).
* There may be cases where a function is meaningful not just with Linux
kernels supporting the syscall, and should be provided with some kind
of fallback for older kernels, and possibly made part of the glibc
API for systems with other kernels as well.
~~~
Cheers,
Carlos.