This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: support for calling Linux syscalls directly
- From: "H. Peter Anvin" <hpa at zytor dot com>
- To: libc-alpha at sourceware dot org
- Date: Thu, 31 Jan 2013 22:01:25 -0800
- Subject: Re: support for calling Linux syscalls directly
- References: <201301242314.47793.vapier@gentoo.org> <5109A662.7050101@zytor.com> <20130131073057.GQ20323@brightrain.aerifal.cx> <Pine.LNX.4.64.1301312309490.13481@digraph.polyomino.org.uk> <510AFCF3.6080109@zytor.com> <20130131233654.GR20323@brightrain.aerifal.cx> <20130131234949.396B12C069@topped-with-meat.com> <20130201001128.GS20323@brightrain.aerifal.cx>
On 01/31/2013 04:11 PM, Rich Felker wrote:
On Thu, Jan 31, 2013 at 03:49:49PM -0800, Roland McGrath wrote:
The approach I proposed was to determine what's "glibc material". I
suspect everything that's not does not belong in a library at all. If
the syscall is specific to a single package (like modutils), then the
package (e.g. modutils) maintainers are going to be a lot more
competent dealing with the kernel interface than a third party trying
to maintain libinux.
The plan is that libinux be maintained along with the kernel, which is by
definition the place that knows the kernel interfaces best as they change.
I thought kernel interfaces were permanent and weren't allowed to
change... Making a library that's intended to be used to access them
with the idea that they "might change" sounds like a dangerous
precedent towards weakening the stability of the kernel API/ABI.
The way they might change include things like:
1. We deprecate an old syscall number and assign a new one with a
different ABI;
2. An architecture with multiple ABIs create a new one;
3. The wrapper function in the library itself is buggy and needs to be
fixed.
2 & 3 require some explanation, I believe. On architectures like ARM,
some system calls will have nonstandard argument ordering or other
evilness due to the fact that ARM has to support multiple conflicting
ABIs, and so the system calls get "hand tuned." In that case the stubs
will not be just the trivial ones but will have to translate between the
common API and the arch-specific ABI.
One of the very problems with syscall(3) we want to avoid here is the
fact that syscall(3) exposes any ABI anomalies directly to the programmer.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.