Re: support for calling Linux syscalls directly

[Rich Felker <dalias at aerifal dot cx>]

On Mon, Feb 04, 2013 at 05:19:10AM +0100, Michael Kerrisk wrote:
> On Mon, Feb 4, 2013 at 4:43 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> > On 02/03/2013 07:35 PM, Michael Kerrisk wrote:
> >>
> >>
> >> So, below my (expanded) list of syscalls that don't have ful glibc
> >> support, categorized with respect as to whether they should be in
> >> glibc.
> >>
> >
> > From the the looks of it you're assuming library == libc, as opposed to
> > making a libc/libinux distinction.
> 
> Yes, I am more or less doing that. gettid() is an example of why.
> There are by now many glibc syscall wrappers that employ kernel thread
> IDs. Thus, it's quite strange that gettid() is not in glibc.

I think the issue is that either nobody realized these functions were
using tids rather than pids, or they wanted to brush the distinction
under the rug. This is really unfortunate, as a number of these
functions _should_ be taking pids but it's probably too late to fix
them...

> io_prioset/ioprio_get is another example that seems to me to fairly
> clearly belong in glibc. There are many other Linux-specific system
> calls that I would imagine are roughly as widely used that are already
> in glibc, which makes the omission of these two look odd.
> 
> To a (possibly) lesser degree one can make the same argument about
> each of the syscalls that I put in the POSSIBLE category. One could
> argue that some of those system calls could go in a liblinux, but the
> decision to put some wrappers in such a library as opposed to libc
> seems very arbitrary, especially when one considers that so many Linux
> specific syscalls already have a wrapper in glibc (e.g., eventfd(),
> splice(), capget() and friends, getxattr() and friends, inotify*(),
> iopl(), remap_file_pages(), setns(), unshare(), and on and on)

I'm largely against libinux. There does not seem to be any compelling
reason for making a new library to hold 500 bytes of syscall wrapper
code, and I agree the distinction of what goes there versus libc seems
arbitrary and confusing.

Rich