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 ) id 1R1lA9-000614-SQ for garchives@archives.gentoo.org; Thu, 08 Sep 2011 20:25:30 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8B7B021C1B0; Thu, 8 Sep 2011 20:25:11 +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 5218521C28C for ; Thu, 8 Sep 2011 20:23:38 +0000 (UTC) Received: by wyg36 with SMTP id 36so1206046wyg.40 for ; Thu, 08 Sep 2011 13:23:37 -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=eojY/E21M6AGs32Q2gIL7LNfLZJ0HL0h6R51cz88F1s=; b=AjzUB/iGooTsWQ9InJ1J4e1tBBT79P7ooDs2fM0vJx65Y+OTZQdwsvVIujgiVl8LIw aljvCKXwTHgC8xcIiZeGXlVwkwHnyo0Ynft3d/2dyBbqmR8dARsdtad0yFFMjNQQy6wF Fh1lKviBubrb7kmEYsV8V1x2C1ZTFavbsuXXo= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.216.71.76 with SMTP id q54mr267623wed.83.1315513417511; Thu, 08 Sep 2011 13:23:37 -0700 (PDT) Received: by 10.216.39.140 with HTTP; Thu, 8 Sep 2011 13:23:36 -0700 (PDT) In-Reply-To: <20110908220536.55dd3798@rohan> References: <201108191109.34984.michaelkintzios@gmail.com> <4842477.AF29R6J79c@pc> <12534676.jn0Id4Zse9@pc> <20110908220536.55dd3798@rohan> Date: Thu, 8 Sep 2011 16:23:36 -0400 Message-ID: Subject: Re: [gentoo-user] /dev/sda* missing at boot From: =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw6lz?= To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 96943c7e29a616482334a741d82093b7 On Thu, Sep 8, 2011 at 4:05 PM, Alan McKinnon wro= te: > On Thu, 08 Sep 2011 19:11:04 +0200 > Michael Schreckenbauer wrote: > >> > 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. >> >> Where did I write, that I am in the position to write such a beast? >> I only take the freedom to name this a design flaw in udev. >> It needs things from userspace, which are not yet available at the >> point it requests them. An initramsfs is a workaround for this, not a >> proper fix. > > If that is the argument from the udev devs you just quoted, then I do > not understand it at all. > > Why can there not be a restriction that udev may only run code in the > traditional / space (i.e. it will not attempt to run code in the /usr > or /home spaces)? > > Device nodes are a root function; root is the only user that should > dictate how device nodes are created; root is the only user that can > normally write to / and thereby create udev's rules and rulesets. > > In what valid way does access to /usr become something that udev may be > required to support? It is a matter of what else do you end having in /bin and /lib. Remember that udev rules can execute arbitrary code. Do all that code needs to be moved to /bin and /lib also? I keep telling: it is a difficult problem. 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