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

The kernel and the C library as a single project

Posted Nov 30, 2010 21:05 UTC (Tue) by sfeam (subscriber, #2841)
In reply to: The kernel and the C library as a single project by nix
Parent article: The kernel and the C library as a single project

Actually, making libc a kernel module would have the opposite effect. Whereas now if you manage to install a bad libc your system is unusable, if it were instead a matter of installing a new kernel version with a bad libc then you could just boot into the previous kernel and your good libc would come back with it.

to post comments

The kernel and the C library as a single project

Posted Nov 30, 2010 21:12 UTC (Tue) by madscientist (subscriber, #16861) [Link] (3 responses)

"Making libc a kernel module"? Was that suggested somewhere? I don't even know what that means.

The kernel and the C library as a single project

Posted Nov 30, 2010 22:27 UTC (Tue) by sfeam (subscriber, #2841) [Link] (2 responses)

It was suggested in an earlier response to this article (by pj). But yeah, I don't know exactly what that would mean either.

Libc as a module ...

Posted Dec 1, 2010 12:06 UTC (Wed) by AnswerGuy (guest, #1256) [Link]

Concievably one could use a design similar to the VDSO "linuxgate" which was part of the Linux threads NG support a few years ago.

A default might simply implement the same mmap/linkage semantics that are in use already. However, any specific kernel image could over-ride that behavior.

I'm not advocating such an approach. I'm merely speculating on what someone might reasonably mean by saying such things.

The kernel and the C library as a single project

Posted Dec 3, 2010 19:34 UTC (Fri) by Spudd86 (guest, #51683) [Link]

Well that wasn't the suggestion, it the suggestion was basically make linuxgate.so into libc. (OR at least make libc work like linuxgate.so, probably making it relocatable, unlike linuxgate)

The kernel and the C library as a single project

Posted Dec 1, 2010 16:27 UTC (Wed) by nix (subscriber, #2304) [Link] (4 responses)

Uh, you can't make libc a kernel module. It is both a userspace program and contains a component (ld-linux.so.2, the dynamic loader) whose absolute filename is wired into every dynamically linked binary on the entire system.

I suppose you could perhaps have a scheme where the kernel reads a PT_INTERP of '/lib/ld-linux.so.2' and looks for /lib/lds/{kernel version}/ld-linux.so.2 first, but I suspect this would have trouble getting upstream, because one extra path lookup per exec() is quite a cost.

Pity Linux doesn't support virtual files or filesystem

Posted Dec 1, 2010 19:07 UTC (Wed) by kmself (guest, #11565) [Link] (3 responses)

Oh wait, scratch that.

/proc, /sys, /lib-ld-linux.so.2, /usr/games/nethack ....

Actually, since /lib/ld-linux.so.2 is already a symlink, it'd be even easier.

ls -l /dev/std{in,out,err} f'rex.

Pity Linux doesn't support virtual files or filesystem

Posted Dec 2, 2010 14:39 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

Yeah, that would work. Kinda weird to have your libc provided by the kernel but I don't see a fundamental problem with it... except that the machinery in the kernel to export things like the vdso to userspace would need a *lot* of retooling to be able to export things as big as a C library.

Pity Linux doesn't support virtual files or filesystem

Posted Dec 3, 2010 5:09 UTC (Fri) by jzbiciak (guest, #5246) [Link] (1 responses)

Could it be built / linked to a kernel similarly to an initrd? The main thing you'd lose is the ability to page it out, I imagine...

Pity Linux doesn't support virtual files or filesystem

Posted Dec 4, 2010 23:05 UTC (Sat) by nix (subscriber, #2304) [Link]

ld-linux.so.2 is never really paged out anyway. It's only a dozen pages long and all of it is in use by *something* nearly all the time.