C library system-call wrappers, or the lack thereof

Posted Nov 14, 2018 1:24 UTC (Wed) by marduk (subscriber, #3831)
In reply to: C library system-call wrappers, or the lack thereof by ermo
Parent article: C library system-call wrappers, or the lack thereof

Linux did once have it's own libc (a fork of glibc). And then they went (back) to glibc. I think the thinking at the time was that it was undeserable to maitain a libc and the kernel and that the kernel devs were only interested in certain aspects of the C library whereas some other parts that "real" people use weren't getting enough attention.

C library system-call wrappers, or the lack thereof

Posted Nov 14, 2018 16:40 UTC (Wed) by matthewbauer (guest, #128608) [Link] (1 responses)

I think you’re referring to klibc. And it still is in use - just internally with Linux. I don’t think it was ever intended as a general libc replacement.

C library system-call wrappers, or the lack thereof

Posted Nov 14, 2018 16:55 UTC (Wed) by marduk (subscriber, #3831) [Link]

I'm talking about "linux libc" (I don't think there was an official name for it".

http://freesoftwaremagazine.com/articles/history_of_glibc...

I remember the pains of migrating a Slackware box from "libc5" (linux libc) to "libc6" (GNU libc 2).

C library system-call wrappers, or the lack thereof

Posted Nov 29, 2018 9:10 UTC (Thu) by hensema (guest, #980) [Link]

> I think the thinking at the time was that it was undeserable to maitain a libc and the kernel and that the kernel devs were only interested in certain aspects of the C library whereas some other parts that "real" people use weren't getting enough attention.

That's why a split of the C library is needed. One part is the syscall stuff (let's call it liblinux for now) and the other part is the C library with all of its string manipulation, memory management, pam, etc, etc.

This would let kernel devs also develop the userspace counterparts of their system calls while not burdening them with all the other stuff a C library must do. liblinux could even be statically linked into glibc if you want to avoid changing all Makefiles in the world.

Another advantage is that liblinux would become the new ABI, whereas the userspace/kernelspace interface could undergo changes once in a while. And we'd have a REAL reason to increase the kernel major version ;-)