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: Michael Kerrisk <mtk dot manpages at gmail dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: libc-alpha at sourceware dot org, "Joseph S. Myers" <joseph at codesourcery dot com>, Roland McGrath <roland at hack dot frob dot com>, hpa at zytor dot com, keescook at chromium dot org, mtk dot manpages at gmail dot com
- Date: Mon, 4 Feb 2013 04:35:40 +0100
- 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>
On Fri, Feb 1, 2013 at 12:36 AM, Rich Felker <dalias@aerifal.cx> wrote:
> On Thu, Jan 31, 2013 at 03:23:31PM -0800, H. Peter Anvin wrote:
>> On 01/31/2013 03:10 PM, Joseph S. Myers wrote:
>> > On Thu, 31 Jan 2013, Rich Felker wrote:
>> >
>> >> What I'd like to see is an honest reevaluation of the currently
>> >> missing syscall wrappers glibc doesn't provide. If there are some that
>> >> libc should provide, let's get them added. If they're really not meant
>> >> to be used except in a single application (or not at all -- deprecated
>> >> junk) then they can just be left alone.
>> >
>> > I agree with that approach - with the requirement that any new syscall
>> > wrapper added must have a prototype included in some header that glibc
>> > installs.
>>
>> I agree we should do this for things that are "glibc material".
>
> The approach I proposed was to determine what's "glibc material". I
> suspect everything that's not does not belong in a library at all. If
> the syscall is specific to a single package (like modutils), then the
> package (e.g. modutils) maintainers are going to be a lot more
> competent dealing with the kernel interface than a third party trying
> to maintain libinux.
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.
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)
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]