Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Mike Frysinger <vapier <at> gentoo.org>
Subject: support for calling Linux syscalls directly
Newsgroups: gmane.comp.lib.glibc.alpha
Date: Friday 25th January 2013 04:14:46 UTC (over 4 years ago)
spawning a new thread w/summarized info because the previous ones were
going 
in circles of "read the previous thread".  so i read them.

to summarize, the anti-arguments were:
 - it pollutes the ABI
 - it takes up code space and sits there largely unused
 - there are few users to justify the overhead
 - people can use syscall() directly
 - the kernel people could provide their own header

while the pro-arguments are:
 - we already have a bunch syscall trampolines, some very old (init_module)

while others are recent (process_vm_readv, setns)
 - having a single "authoritative" prototype location is better than people

open coding it in every project (especially when documentation is often
scare 
to non-existent) because it's very error prone
 - a kernel header easily introduces API (define/enum/structure/etc...) 
collisions (see recent network header thread as an easy example) that are
non-
trivial to resolve

looking at linux/syscalls.list, there's actually quite a number in there
that 
i'd classify on the "uncommonly used" side, although i'll grant that kexec
is 
pushing the edge.

from the "pro" pov, i don't think people care whether the syscall is in the

shared C library and part of the official ABI.  the focus is on there being
1 
header for code to include.  so i wonder if we couldn't satisfy people by 
providing either static inlines or a libsyscall_nonshared.a that is
referenced 
via the libc.so linker script.
-mike

http://sourceware.org/ml/libc-alpha/2013-01/msg00840.html
[finit_module]
http://sourceware.org/ml/libc-alpha/2012-06/msg00048.html
[kexec v5]
http://sourceware.org/ml/libc-alpha/2012-05/msg01645.html
[kexec v4]
http://sourceware.org/ml/libc-alpha/2012-05/msg01630.html
[kexec v3]
http://sourceware.org/ml/libc-alpha/2012-05/msg01623.html
[kexec v2]
http://sourceware.org/ml/libc-alpha/2012-05/msg01620.html
[kexec v1]
 
CD: 4ms