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: Michael Kerrisk <mtk dot manpages at gmail dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, libc-alpha at sourceware dot org, "Joseph S. Myers" <joseph at codesourcery dot com>, Roland McGrath <roland at hack dot frob dot com>, keescook at chromium dot org
- Date: Sun, 03 Feb 2013 19:43:21 -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> <CALxWeYqKWT=ww+EY4VWgfYaW62_=VGuHZqcGzbxykUnnhf1aAA@mail.gmail.com>
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.
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.