The kernel and the C library as a single project [LWN.net]

The kernel and the C library as a single project

Posted Dec 1, 2010 2:49 UTC (Wed) by RogerOdle (subscriber, #60791)
Parent article: The kernel and the C library as a single project

This is a bad idea. It amounts to creating a fork of glibc that will forever cause compatibility problems. It would expand the responsibility of the kernel maintainers to also include the maintenance of what is essentially not kernel code. They have enough to do already.

What problem are you trying to solve? glibc developers are not accepting changes to the API fast enough? They shouldn't allow the core interfaces for Linux applications to change quickly or easily as that would undermine the stability of the Linux environment and the confidence of the users. Why is it important for some particular function to be added to the c library? It is not that difficult to build a library for Linux and install it.

One of the main problems with glibc now is its size. For some embedded projects, glibc is just too big already. This issue is addressed by using reduced glibc alternatives or custom modifications of glibc itself. Neither solution is entirely satisfactory.

What is needed is to concentrate of sound engineering principals; particularly the one that Microsoft has never learned. That reliability and maintainability requires that things be kept as simple as practical. Do not add to the kernel developers the responsibility for the user space libc. The glibc maintainers have been doing an adequate job while not chasing every fad that comes along.

When Microsoft extends its operating system with Office code and Outlook code, it compromises reliability and security. Microsoft does not do this for any good engineering reason, they do it for a business reason. They do it to control the market.

The reasons for not combining libc with the kernel far out weigh the benefits. Please do not do this.

to post comments

The kernel and the C library as a single project

Posted Dec 1, 2010 6:29 UTC (Wed) by eru (subscriber, #2753) [Link]

Agreed! The original problem can be solved much better by improving the libc development, not by mashing it with the kernel. Maybe there could be some Linux-specific glibc fork that is updated very frequently to take advantage of the latest kernel features, but it must not be a part of the kernel in any sense, and must be replaceable by a totally different library if needed (this demands the kernel interface stays well-defined).

The kernel and the C library as a single project

Posted Dec 2, 2010 13:43 UTC (Thu) by i3839 (guest, #31386) [Link]

Agreed. It's a bloody bad idea.

More problems would be solved if the kernel would drop bad system calls before they are in widespread use, instead of the stupid "stable ABI forever, even new bad ABI" mindset. The sooner crap is removed, the better. Only once it's in widespread use it's bad to break the ABI. But that can only happen if you didn't remove the bad ABI early enough. I hope one day Linus gets a clue about this.