Re: support for calling Linux syscalls directly

[Michael Kerrisk <mtk dot manpages at gmail dot com>]

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.

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)

Cheers,

Michael


>
>
>> Cheers,
>>
>> Michael
>>
>>
>> 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)
>> io_cancel(2)
>> io_destroy(2)
>> io_getevents(2)
>> io_setup(2)
>> io_submit(2)
>> kcmp(2)
>> kexec_load(2)
>> perf_event_open(2)
>> tgkill(2)
>>
>>
>> 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]
>>
>>
>> INTENDED ONLY FOR LIBC / KERNEL USE
>> (No need to add a wrapper in glibc)
>>
>> restart_syscall(2)
>>
>>
>> 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() and pivot_root() definitely should have library
> implementations.  The others are iffier, it depends on if you consider them
> to be strictly for implementing locking primitives and TLS respectively.
>
>
>>
>> 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)
>>
>>
>> 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)]
>>
>>
>> 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]
>>
>
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.
>