| |||||||||||||
The kernel and the C library as a single projectThe kernel and the C library as a single projectPosted Nov 30, 2010 20:37 UTC (Tue) by JoeBuck (subscriber, #2330)Parent article: The kernel and the C library as a single project Given the huge rate of change of the kernel, the fact that the separateness of glibc imposes a speed bump, and that cool new kernel interfaces (that might disappear with the next release) are tricky to access until glibc's developers have agreed to add support, might not really be such a problem and could be seen as a feature.
(Log in to post comments)
The kernel and the C library as a single project Posted Nov 30, 2010 20:55 UTC (Tue) by nix (subscriber, #2304) [Link]
Also, upgrading your C library is dangerous. It's just about the only thing in the system where if you mess up installing it, or build a broken version and don't run 'make check', you break your whole system at once with no way back without use of an emergency boot disk, a netboot, or a statically linked emergency busybox shell (which you must have prepared in advance, of course, as with no working libc you're not going to be able to compile or install it after the fact). None of that is true of the kernel, unless you're unlucky enough to install a kernel that scrags your filesystem.
I'm happy to install new kernels frequently. I'm much less happy to install new glibcs frequently: I'm on tenterhooks even when a distribution glibc upgrade comes down the pipe, because I have known *those* to scrag my whole system in the past as well.
The kernel and the C library as a single project Posted Nov 30, 2010 21:05 UTC (Tue) by sfeam (subscriber, #2841) [Link]
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.
The kernel and the C library as a single project Posted Nov 30, 2010 21:12 UTC (Tue) by madscientist (subscriber, #16861) [Link]
"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]
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]
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 (subscriber, #11565) [Link]
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]
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.
The kernel and the C library as a single project Posted Nov 30, 2010 22:51 UTC (Tue) by gerdesj (subscriber, #5446) [Link]
I don't know what sort of distro you are using but on Gentoo I have upgraded glibc a huge number of times with no problems on countless (x) machines.
{x < "have to take someone else's shoes off to count"}
I also have had no problems with a non trivial number of RedHat, CentOS, Man{drake|driva}, OpenSuSE, SLES/SLED and others.
Perhaps your distro's dependency checker or your use of it is at fault.
Cheers
The kernel and the C library as a single project Posted Nov 30, 2010 23:15 UTC (Tue) by madscientist (subscriber, #16861) [Link]
Most likely nix just has a longer memory than you :-). I, too, remember when upgrading libc was a major cause of hair lossage and nail-biting.
But, I've not had any problems in probably 10 years or so... and I never shy away from an upgrade when it's offered to me. Modern distros definitely do this right.
The kernel and the C library as a single project Posted Dec 1, 2010 9:44 UTC (Wed) by cate (subscriber, #1359) [Link]
glibc learned how to make stable ABI, so now (last 10-12 years) upgrades are easy. IIRC the big improvement was to reserve extra space for structures, to allow library improvement without breaking ABI. (but wasting some more memory)
Probably also the c compiler is more conservative between ABI and optimisation. Actually c++ ABI is not so stable, but this cause less problem: init will anyway start, as well the essential things, thus allowing restoring systems.
BTW: libc upgrades was a nightmare because LILO cannot boot an old library, and live CD were non existent.
The kernel and the C library as a single project Posted Dec 1, 2010 16:30 UTC (Wed) by nix (subscriber, #2304) [Link]
The worry here is not 'the ABI breaks'. The worry here is 'it compiled, but if you run it it is too buggy to run significant programs without crashing'. Anything from miscompilation to buggy toolchains to general build environment problems to installation problems to a buggy glibc can do this.
The reason why glibc works when distros package it is because they take a lot of care, because they run 'make check', and because they know from experience which longstanding test failures indicate real problems. 'make check' takes, oh, half an hour on a fast Nehalem. This is not something that would add only a small amount of time to a kernel build!
The kernel and the C library as a single project Posted Dec 3, 2010 21:07 UTC (Fri) by Darkmere (subscriber, #53695) [Link]
A few Gentoo users got bit by that by trying out the gold linker. When you end up with a 64bit linker that dumps core when linking something major, like gcc, you have a somewhat usable but ultimately badly broken system.
So yeah, infrastructure upgrades like bash, glibc, gcc, binutils, python make us all _very very_ concerned. It may not be noticable at first, but if it causes bad code generation or breaks on non-trivial things, you end up with a nightmare to recover.
The kernel and the C library as a single project Posted Dec 4, 2010 19:38 UTC (Sat) by nix (subscriber, #2304) [Link]
Indeed Fedora just got hit with a mass rebuild due to just such a codegen bug in GCC's 4.5 branch (never released, but Fedora update periodically to tip-of-branch rather than using releases, so they were hit, and had to rebuild everything built with the buggy compiler).
The kernel and the C library as a single project Posted Dec 1, 2010 11:17 UTC (Wed) by NAR (subscriber, #1313) [Link]
Hmm, I think it wasn't that long ago when glibc broke (OK, exposed an already exiting bug in) flash on Fedora...
The kernel and the C library as a single project Posted Dec 1, 2010 14:07 UTC (Wed) by madscientist (subscriber, #16861) [Link]
Meh. A non-working flash definitely does not qualify for my definition of hair pulling or nail-biting. Does your system boot without having to get out a boot disk, mount your root partition, and do major surgery? Then you're good.
The kernel and the C library as a single project Posted Dec 3, 2010 9:47 UTC (Fri) by job (guest, #670) [Link]
Indeed.
Another thing that causes hair pulling but should be fairly straightforward is executable file format migrations. _Every_time_ that has caused problems.
;-)
|
|||||||||||||