Alan Cox wrote:
quoted text
>> (*) Not saying that a klibc-based initramfs is necessarily smaller than 
>> the in-kernel code it replaces, but the total size is << than the size 
>> of the kernel proper, which isn't true when using a full-featured libc.
> 
> True but with a vendor hat on thats not usually a problem on modern
> systems and using glibc means less code to maintain, less special cases,
> and more flexibility.
> 
> For embedded klibc may well be interesting.

For vendor hat meaning full-blown systems, yes that is true, but for 
embedded, or even on some "real" platforms, that definitely matters.

Fundamentally, however, we're never going to have a full-blown libc 
environment built out of the kernel tree, as its size would be 
comparable or larger than the kernel itself.

	-hpa
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/