Historically, the C library on Linux has provided the low-level system call interface, the POSIX functions (which wrap the system calls for the most part) and the standard C functions. Why do we need all these disparate parts in a single library?
Could the system call interface be wrapped and placed in a completely separate library, e.g. libsystem, which the POSIX and/or C libraries could then use?
If there was ever a library which could use some simplification, it's glibc. Its build system is impenetrable and its sources often incomprehensible (to a newcomer).
Posted Dec 1, 2010 11:21 UTC (Wed) by michaeljt (subscriber, #39183)
[Link]
> Historically, the C library on Linux has provided the low-level system call interface, the POSIX functions (which wrap the system calls for the most part) and the standard C functions. Why do we need all these disparate parts in a single library?
I was just about to voice those very thoughts.
The kernel and the C library as a single project
Posted Dec 1, 2010 11:58 UTC (Wed) by jlayton (subscriber, #31672)
[Link]
Hear hear!
This is the sanest idea yet. Sounds simple (in principle) to break the syscall interfaces out of libc and into a separate lib. libc could then be built with dependencies on the new library, thereby maintaining backward compatability.
I'm sure there are all sorts of nasty details I haven't considered, but it sounds like a step in the right direction.
The kernel and the C library as a single project
Posted Dec 4, 2010 0:24 UTC (Sat) by oak (subscriber, #2786)
[Link]
And if it would be a real dynamic library (instead a kernel emulated one), intercepting file system calls would be much easier. Currently libc functions can internally do all kinds of interesting things, but with syscalls being in a separate library they could simply be cought with an LD_PRELOAD...
(And the other alternative for interception, ptrace(), changes signaling semantics and race-free interception of calls in threaded code with ptrace() needs architecture specific code.)