This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

support for calling Linux syscalls directly

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 linker script.
-mike [finit_module] [kexec v5] [kexec v4] [kexec v3] [kexec v2] [kexec v1]

Attachment: signature.asc
Description: This is a digitally signed message part.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]