Re: support for calling Linux syscalls directly

["H. Peter Anvin" <hpa at zytor dot com>]

On 01/24/2013 08:14 PM, Mike Frysinger wrote:
> 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.

I have had a number of discussions with people on this topic,
especially given that syscall(3) is fundamentally flawed on a number
of architectures, and that some architectures have been forced to use
nonstandard signatures, complicating things.

What I think makes sense is to create a library separate from glibc
presumably called libinux containing the Linux-specific bits.  This
libinux could ideally not just service glibc but also uClibc and
Bionic (klibc itself is a little too "special" in that it doesn't have
a dynamic linker at all.)

My intent was to revamp the infrastructure from klibc to create
libinux, and eventually try to get it into the Linux kernel tree so
that when new oddball system calls are added we can get everything in
one place -- headers (with the recent uapi work), library, and of
course the kernel itself.

The "red line" for this library should be if it interacts with
non-kernel data types in any kind of nontrivial way.

What do you think?

	-hpa