From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-user+bounces-127839-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1R1hmI-0004X6-Nk
for garchives@archives.gentoo.org; Thu, 08 Sep 2011 16:48:41 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id CEA8921C373;
Thu, 8 Sep 2011 16:48:03 +0000 (UTC)
Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181])
by pigeon.gentoo.org (Postfix) with ESMTP id 556E821C119
for <gentoo-user@lists.gentoo.org>; Thu, 8 Sep 2011 16:45:48 +0000 (UTC)
Received: by wyg36 with SMTP id 36so976643wyg.40
for <gentoo-user@lists.gentoo.org>; Thu, 08 Sep 2011 09:45:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type:content-transfer-encoding;
bh=Az0Ec2fXzHd7UXimouMDDlpER3pP7b3f4MXoZS2Btfg=;
b=wM0dc8eMureYi8/ZI5HUA5aq+aJUbJhBs4YkGxZrrePXfm3mGIpH2KZmGzxX9HhgJG
R54IoiWTDMp+91D4tjS8MqrERf8GV3NwoRiuf9UwyM9RUh6xLLsuzzhRqeve5FPCfz8h
Kdii0GAxkm8qHfhTLPNnT2Deb9etWcxbCSOoM=
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.216.181.141 with SMTP id l13mr911877wem.98.1315500347467; Thu,
08 Sep 2011 09:45:47 -0700 (PDT)
Received: by 10.216.39.140 with HTTP; Thu, 8 Sep 2011 09:45:47 -0700 (PDT)
In-Reply-To: <4842477.AF29R6J79c@pc>
References: <201108191109.34984.michaelkintzios@gmail.com>
<CA+czFiA8qM2h4LQ+QY6p48o_0JCaThuPoRLd-_Um4Tbd=Anh1A@mail.gmail.com>
<20110908165822.442f3097@zaphod.digimed.co.uk>
<4842477.AF29R6J79c@pc>
Date: Thu, 8 Sep 2011 12:45:47 -0400
Message-ID: <CADPrc8047KkveLDc91Fq__mQA-=8kwghEpPYPr9byGd5JNGt=A@mail.gmail.com>
Subject: Re: [gentoo-user] /dev/sda* missing at boot
From: =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw6lz?= <caneko@gmail.com>
To: gentoo-user@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt:
X-Archives-Hash: 244d29e00042a5231a0db1c4337d0d69
On Thu, Sep 8, 2011 at 12:11 PM, Michael Schreckenbauer <grimlog@gmx.de> wr=
ote:
> Am Donnerstag, 8. September 2011, 16:58:22 schrieb Neil Bothwick:
>> On Thu, 8 Sep 2011 11:15:40 -0400, Michael Mol wrote:
>> > Perhaps udev's problem is that it's too complex, as a result of having
>> > too large a problem scope.
>
>> The problem, AIUI, is the udev can run any programs specified in the
>> rules files, and they may not be available before /usr is mounted.
>
> Funny thing is, devfs was removed, because of "unfixable race-conditions"
> (among other things iirc). What else is this then?
> An initramfs is not a proper fix for this design flaw, imo.
Then design the correct solution and implement it. If it's technically
sound, it will prevail. I think it's a rather complicated problem with
a non trivial solution, but the code is there if you feel like give it
a try.
devfs was replaced by udev primarily because devfs shoved a lot stuff
in the kernel (the rules to create the devide nods) that belongs in
users pace. And I agree: the rules to determine what devices nodes
gets created by what hardware (that nowadays hardware appears and
disappears almost randomly from the kernel point of view), belongs in
user space. And guess what? Then to boot you need a minimal user
space. And the fool-proof way to get one before mounting anything, is
to put it in an initramfs.
Embedded systems don't need that, and deal with it in a particular way
(device-trees and other stuff). Desktop and servers can use (and I
think should use) an initramfs (yes, servers too, especially with
eSATA and similar things). The kernel devs have been moving in that
direction for a long time.
I would not be surprised that the option to not have initramfs will be
removed from the kernel in the future, unless you select
CONFIG_EMBEDDED=3Dy.
Regards.
--=20
Canek Pel=C3=A1ez Vald=C3=A9s
Posgrado en Ciencia e Ingenier=C3=ADa de la Computaci=C3=B3n
Universidad Nacional Aut=C3=B3noma de M=C3=A9xico