[arch-dev-public] Dumping klibc (WAS: Re: Changing raid/raid-partitions initcpio hooks)

Aaron Griffin aaronmgriffin at gmail.com
Thu Feb 19 10:53:17 EST 2009


On Wed, Feb 18, 2009 at 8:42 PM, Dan McGee <dpmcgee at gmail.com> wrote:
> On Wed, Feb 18, 2009 at 7:38 PM, Thomas Bächler <thomas at archlinux.org> wrote:
>> Tobias Powalowski schrieb:
>>>
>>> Now comes the point, to achive this, mdadm will be needed in initramfs
>>> which means having a 900k static binary in early boot sequence.
>>> (raid-partitions hook already uses this binary)
>>
>> I am really annoyed by the fact that almost nothing builds against klibc.
>>
>> Wouldn't it be easier to switch to uclibc and busybox? Both are much more
>> powerful and we wouldn't need static binaries for lvm, cryptsetup or mdadm.
>> We would also have much less problems with all the ABI changes that happen
>> with klibc.
>>
>> I thought we needed a complete toolchain for that, but Jan claimed that it
>> is possible to use our normal gcc and binutils for that.
>
> I would be in support of this, as I have seen some of the headaches
> you have had to deal with when it comes to klibc. Assuming the initrd
> images wouldn't be insanely sized, I don't think this is a problem.
>
> The only real point of klibc is that it is much much smaller than a
> full-blown glibc, correct?

I'd be for it too, but I'd like to actually SEE an implementation
before we commit to anything. This will increase our initramfs size,
but it will also give us more functionality.

I don't imagine much would need changing - just some of the tools used
in the base mkinitcpio hook... and maybe removal or recompilation of
much of the klibc-extras utilities.

At the very least, we could stick a uclibc package in extra so that we
could begin playing with this, right?


More information about the arch-dev-public mailing list