Re: support for calling Linux syscalls directly

[Rich Felker <dalias at aerifal dot cx>]

On Mon, Feb 04, 2013 at 04:35:40AM +0100, 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.

Thanks!

> STRONG CANDIDATES FOR GLIBC
> 
> gettid(2)             See http://sourceware.org/bugzilla/show_bug.cgi?id=6399
> ioprio_get(2)
> ioprio_set(2)
> 
> POSSIBLE CANDIDATES FOR GLIBC
> 
> delete_module(2)      [calling signature changed in 2.6.x]
> finit_module(2)
> init_module(2)

I'm indifferent on these. Probably only modutils should be using them.

> io_cancel(2)
> io_destroy(2)
> io_getevents(2)
> io_setup(2)
> io_submit(2)

There may be some existing lib for these, although if there is I
question the reasoning behind that...

> kcmp(2)
> kexec_load(2)
> perf_event_open(2)
> tgkill(2)

These sound like they belong in libc.

> ARCHITECTURE SPECIFIC, maybe candidates for glibc
> 
> kern_features(2)      [Sparc94]
> s390_runtime_instr(2) [s390 specific]
> spu_create(2)         [PowerPC specific]
> spu_run(2)            [PowerPC specific]
> subpage_prot(2)       [PowerPC specific]
> utrap_install(2)      [Sparc]

I think arch-specific is a class that definitely doesn't need library
wrappers. One of the motivations for library-level wrappers is to
shield applications from arch-specific argument orders/variants/etc.
of some syscalls. If the syscall only exists on a particular arch and
is only used for special purposes such as arch-specific virtualization
or JIT code, then the syscall() or asm-syscall can just go in the
application that's using it...

> INTENDED ONLY FOR LIBC / KERNEL USE
> (No need to add a wrapper in glibc)
> 
> restart_syscall(2)

Indeed, this one is impossible to use from userspace; it depends on
kernel internals outside userspace control.

> UNCERTAIN (some possibly only intended for libc use)
> 
> get_robust_list(2)
> set_robust_list(2)
> get_thread_area(2)
> set_thread_area(2)
> modify_ldt(2)
> pivot_root(2)

modify_ldt is arch-specific.

pivot_root almost certainly should be in glibc.

The other four are much more questionable. One criterion on which they
should perhaps be excluded is that they can't be used safely with
glibc, i.e. changing the thread pointer or robust-list pointer for a
thread will interfere with the operation of glibc internals, possibly
even in non-multithreaded programs. As such, I would say these
syscalls are only for internal use in glibc, use in non-glibc libcs,
or use in applications written in asm or using minimal non-glibc libcs
(such as klibc) that don't care about the thread pointer.

Also, set_thread_area does not even exist on all archs. On x86_64,
arch_prctl is used to achieve the same effect. On powerpc, a simple
userspace register-move instruction is used to store the pointer into
a general-purpose register. On i386, the syscall exists, but rather
than taking a thread pointer as the argument it takes a user_desc
structure. So if glibc were to support set_thread_area, it would need
to deal with these differences...

> NO GLIBC WRAPPER, BUT WRAPPER IN LIBNUMA
> 
> (This is an odd situation. No obvious reason why
> things are done this way.)
> 
> get_mempolicy(2)
> mbind(2)
> migrate_pages(2)
> move_pages(2)
> set_mempolicy(2)

Agreed, this makes no sense. But if it's how it is, it might just be
best to leave it alone. I have no strong opinion.

> SYSCALLS WRAPPED IN A GLIBC FUNCTION
> (No need to add a wrapper in glibc)
> 
> getcpu(2)             [there is sched_getcpu(3)]
> mq_getsetattr(2)      [but there are suitable mq_*(3) wrappers]
> rt_sigqueueinfo(2)    [there is sigqueue(3)]
> rt_tgsigqueueinfo(2)  [there is pthread_sigqueue(3)]

Indeed, these could largely be seen as "misnamed syscalls". The only
one possibly interesting to export as tgsigqueue (based on
rt_tgsigqueueinfo) which could send a signal based on tid rather than
pthread_t.

> OBSOLETE
> (No need to add a wrapper in glibc)
> 
> getdents(2)           [readdir(3) is preferred]
> query_module(2)       [obsolete]
> readdir(2)            [readdir(3) is preferred]
> sgetmask(2)           [obsolete, use sigprocmask(2) instead]
> ssetmask(2)           [obsolete, use sigprocmask(2) instead]
> sysctl(2)             [deprecated]
> tkill(2)              [obsolete]

I believe some historical systems (maybe even current bsds) export
getdents, and I'm not quite sure why glibc doesn't. See this blog post
for a take on why it might be nice to have:

http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with-ls/

Of course, this person's underlying problem seems to be using some
hideously slow "virtual file system" (fuse?) where each syscall made
multiple round trips to userspace, but at least it's an indication
that there's at least some demand for getdents.

As for tkill, it's kinda a shame it's marked "obsolete" (and probably
not supported on new archs) because the race condition that caused
tgkill to be added to replace tkill is not actually fixed by tgkill.
See http://sourceware.org/bugzilla/show_bug.cgi?id=12889

As for the others, I agree they're obsolete and completely useless.

Rich