[arch-general] initramfs: execute own script

Aaron Griffin aaronmgriffin at gmail.com
Sat Jan 23 22:52:23 EST 2010


On Sat, Jan 23, 2010 at 8:33 AM, Gerardo Exequiel Pozzi
<vmlinuz386 at yahoo.com.ar> 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 at gmail.com>  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.


More information about the arch-general mailing list