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.
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]
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 (✭ supporter ✭, #5246)
[Link]
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.