Re: support for calling Linux syscalls directly

[Rich Felker <dalias at aerifal dot cx>]

On Wed, Feb 06, 2013 at 01:06:18PM -0800, H. Peter Anvin wrote:
> >> This is my position as well, we should just put all the syscall stubs
> >> in libc.
> >>
> > 
> > After seeing the list, I do agree that the case for libinux seems pretty
> > weak.  I don't have a strong opinion on glibc vs libinux, I just want to
> > get rid of syscall(3).
> > 
> 
> On that note, too, though: I don't want a whole bunch of libraries
> implementing their own syscall hooks, either, so if libc doesn't want to
> deal with some subset of system calls then there probably is a need for
> a libinux.
> 
> Which way to go is at this point up to you libc guys.  I am fine either
> way, but I'd like to know what the plan is.

I think the "bunch of libraries" issue has arisen accidentally because
the people working on new syscalls need to a userspace interface to
them without waiting for them to get added into glibc (and the
headache of upgrading glibc). I don't think "libinux" would fix that
issue. What's really needed is a *policy* (preferably sponsored by the
kernel side too) that these stub libraries be considered as temporary
glue, provided in static-library form only (so applications don't get
a DT_NEEDED reference to them that would need to be supported
indefinitely), and integrated into glibc once the interface is mature
and available in stable kernel releases.

Does that sound reasonable?

Rich