This is the mail archive of the libc-alpha@sourceware.org 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] |
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]
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] |