Re: klibc - another libc?

[Michael Tokarev <mjt@tls.msk.ru>]

Roman Zippel wrote:
> Hi,
> 
> On Fri, 9 Jun 2006, Michael Tokarev wrote:
> 
>> But I see a reason for kinit *now*, in its current form - it's
>> compatibility.  Later on, maybe the whole stuff can be removed entirely,
>> to rely on external tools for booting.
> 
> The compatibility code is already in the kernel, just don't call it if 

Isn't kinit/klibc intended to *replace* that whole code in the kernel?

> e.g. there's a /kinit in initramfs. We can add the hooks to the kernel to 
> pull whatever you want into the initramfs and with time we can remove 
> the old code.
> Why create new (temporary?) compatibility code, if the current code is 
> working just fine?

That was partly my question (or something I had in mind but didn't ask).

Well.  It's interesting.

Embedded folks are using uclibc or dietlibc - i see no reason for another
"more small" libc for booting, regular tools (linked against uc or diet)
can be used just fine.

Big systems will usually require some "advanced" stuff like that same
mdadm or lvm - and again, I don't see why regular glibc can't be used
(wich has an advandage - no need to have two versions of the toolset,
linked with klibc and glibc).

The only real reason I see in klibc is to be able to remove all that
'kinit' code from kernel but still be compatible - so that I will
be able to download linux-2.7, make oldconfig all install, and it
Will Just Work (in case I had no initrd/initramfs) - new userspace
kinit will take care of everything removed from kernel code.

In the other words, i see the whole klibc thing as a temporary
compatibility solution.

Did I miss something?

And yes, it's a PITA to have two sets of all the system utilities -
I'd not go this route.  Also, since klibc will have compatibility
problems with kernel API changes, such a 'parallel toolset' needs
to be recompiled on a regular basis, which means not two toolsets,
but many of them (one 'main', and several 'small for boot', for
different kernel versions, linked against different klibc-XXX.so).

The only problem I see with using glibc in initramfs is -- systems
with small amount of memory, where full-blown glibc with all the
required tools will just not fit into ramfs/tmpfs.  Not "embedded"
systems (like boxed routers for example - they're already using
something much more compact than glibc).  Are there such systems
out there still?

/mjt
-
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/