Re: klibc - another libc?

[H. Peter Anvin]

Michael Tokarev wrote:
> You *do* need mdadm to boot from RAID.  Unless you rely on broken,
> obsolete, "don't use" in-kernel raid autodetection code (which, in
> this case, will be moved from kernel space into kinit).  There are
> many reasons why raid autodetection in its current form is not a good
> idea, all goes to simple "unreliable" definition - there where many
> discussions about this already.
>
> Well ok, mdadm/Assemble.c can be merged into kinit instead of current
> stuff present there, and adopted somehow.  Until when, mdadm IS
> necessary.
>
> Ok, the next question may be 'and what about lvm?', or dm, or whatever
> else..  Md autodetection code has been in kernel for a long time,
> while lvm/dm/etc stuff wasn't.  So there IS a difference... ;)
>
> 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.  Existing mkinitrd/mkinitramfs/
> etc solutions works, they're being improved all the time, and they
> don't use kinit.
>
> Did I get it all right?  :)

Pretty much.  :)

However, this also is a good basis to point out that one of the big advantages with klibc 
is that you *can* share code with standalone userspace tools with relative ease.  For 
example, porting mdadm/Assemble.c to be a tool -- be it standalone or integrated into 
kinit -- is a pretty trivial project, whereas trying to integrate code like that into the 
kernel proper is a major task.

As you can also notice, a number of modules of kinit are also available as standalone 
programs (and, in fact, I have already gotten requests to break out additional modules in 
the same way.)  This means that that code is available to distributions to use in their 
initramfs solutions, without having to take the kinit package.  Finally, unlike the 
current code, kinit can be wrapped, as is, from a script.

	-hpa

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