public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: klibc - another libc?
Date: Fri, 09 Jun 2006 23:13:03 +0400	[thread overview]
Message-ID: <4489C83F.40307@tls.msk.ru> (raw)
In-Reply-To: <e6cgjv$b8t$1@terminus.zytor.com>

H. Peter Anvin wrote:
[]
>>  Let's take booting from raid, in this case you need to install
>> mdadm anyway, which could also provide an initramfs version. This
>> way the setup tools can be generated from the same source, which
>> reduces duplication and maintenance overhead.
> 
> You don't need mdadm to boot from RAID.  kinit handles it just fine.

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?  :)

Thanks.

/mjt

  reply	other threads:[~2006-06-09 19:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-07  8:51 klibc - another libc? Michael Tokarev
2006-06-07 21:17 ` H. Peter Anvin
2006-06-07 22:42   ` Roman Zippel
2006-06-08 15:32     ` H. Peter Anvin
2006-06-09 14:13       ` Roman Zippel
2006-06-09 19:02         ` H. Peter Anvin
2006-06-09 19:13           ` Michael Tokarev [this message]
2006-06-09 19:29             ` H. Peter Anvin
2006-06-10  1:28             ` Roman Zippel
2006-06-10 16:24               ` Michael Tokarev
2006-06-10 17:28                 ` Sam Ravnborg
2006-06-11  0:21                 ` Roman Zippel
2006-06-10  1:15           ` Roman Zippel
2006-06-10  6:13             ` Sam Ravnborg
2006-06-10 23:37               ` Roman Zippel
2006-06-13  2:31             ` Paul Dickson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4489C83F.40307@tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox