Recent Features
| |||||||||||||
The kernel and the C library as a single projectThe kernel and the C library as a single projectPosted Nov 30, 2010 21:06 UTC (Tue) by signbit (subscriber, #71372)In reply to: The kernel and the C library as a single project by pj Parent article: The kernel and the C library as a single project
I won't be libc in the kernel runtime but libc in the kernel source code repository. It will still go in /lib/libc.so.$WHATEVER.
What happened to klibc? Wasn't that supposed to stay close and true to the kernel?
(Log in to post comments)
The kernel and the C library as a single project Posted Nov 30, 2010 21:31 UTC (Tue) by johill (subscriber, #25196) [Link]
libc could be a VDSO I guess ...
The kernel and the C library as a single project Posted Dec 1, 2010 8:14 UTC (Wed) by smueller@atsec.com (guest, #68260) [Link]
Considering how vDSO is implemented, why not exporting all system calls as stubs in the vDSO part? This way, user space could simply link to that vDSO AND use the system calls like a normal API without going through the oddities of syscall()?
klibc is direct opposite Posted Nov 30, 2010 22:27 UTC (Tue) by khim (subscriber, #9252) [Link] Klibc is alive and well - but it's direct opposite to what's offered! Klibc is minimalistic libc - enough to run initscripts, certainly now enough to run heavy-duty apps! It offers access to very few syscalls (you don't need much to insmod some modules and create few /dev files) and does not follow "latest and greatest" changes in kernel at all.
The kernel and the C library as a single project Posted Dec 1, 2010 6:14 UTC (Wed) by jamesh (guest, #1159) [Link]
The quote from Ingo talks of making it a VDSO. That is, code mapped into the address space of every new process by the kernel, rather than libraries loaded from the file system by the dynamic linker.
|
|||||||||||||