On Wednesday 30 January 2013 18:01:54 H. Peter Anvin wrote:
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.
could you elaborate on syscall(3) limitations ? we used to have syscall#()
inline funcs exported at various places (including the kernel's own headers),
and those were a pain to maintain as well. PIC issues readily come to mind.
although, if we have explicit buy in from the kernel peeps to maintain it in
all the various userland setups, it should be a much nicer ride.
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.
will the kernel types get namespaced ? or will it rely on the C library to
provide the proper structures (according to relevant standards) ? the problem
we have currently with the network headers is they define the same structure
name. we don't want to have that be the starting point for a new lib, and it
seems like it'd be real easy for that to become more of a problem. another
example is handling of bits that often share the enum/define names such as stat
or fcntl or mmap.
The "red line" for this library should be if it interacts with
non-kernel data types in any kind of nontrivial way.
that's a good boundary to lay down. i fear without rigorous control, it will
be ripe for abuse by people to bypass glibc, or grow into an ugly monolithic
mountain due to feature creep.