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 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]