On Sat, Jan 23, 2010 at 8:33 AM, Gerardo Exequiel Pozzi <vmlinuz386@xxxxxxxxxxxx> wrote: > On 01/23/2010 08:01 AM, Allan McRae wrote: >> >> On 23/01/10 20:39, Alexander Duscheleit wrote: >>> >>> On Fri, 22 Jan 2010 12:25:16 -0600 >>> Aaron Griffin<aaronmgriffin@xxxxxxxxx> wrote: >>> >>>>> Did you mean ulibc? >>>> >>>> No, not uClibc either. We're actually using glibc itself. Other >>>> distros do this as well, as it DOES add a lot of flexibility >>> >>> Just out of curiosity. Was eglibc considered? Why? Why not? >>> >>> I can see, that maintaing just another libc only for minor >>> space benefits in a short-lived initrd doesn't make a lot of sense, but >>> Debian seems to think, that it could even be an all-out replacement for >>> glibc in general. >>> >> >> There is really no advantage to using eglibc if you are on x86 or x86_64 >> systems. Debian will find eglibc appealing because they support all sorts of >> platforms that are not particularly well supported by glibc. >> >> Allan >> > There is at least one advantage. The build system allows to select groups of > functions to compile or not, for example network, ipv6, charsets, locales, > maths, wide-chars, regex, nis, and others. > But maybe not necessary for initramfs. Well, I think the current train of thought is that klibc was such a restricted subset and was difficult to work with and compile things against, using a glibc we already ship and test loses VERY little, so there's no real point in using yet-another restricted subset. I'll be the first person to question the speed reduction due to the size changes, but Thomas has benchmarked it. The simple fact is that while there may be some slowdown, udev detecting modules is still the largest bottleneck.
