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 1R3Cxd-0005Ky-EQ for garchives@archives.gentoo.org; Mon, 12 Sep 2011 20:18:33 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 81B7F21C0B4; Mon, 12 Sep 2011 20:18:21 +0000 (UTC) Received: from karnak.local (cpc2-lutn10-2-0-cust603.9-3.cable.virginmedia.com [81.97.90.92]) by pigeon.gentoo.org (Postfix) with ESMTP id EE1AB21C06C for ; Mon, 12 Sep 2011 20:16:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by karnak.local (Postfix) with ESMTP id 333463003 for ; Mon, 12 Sep 2011 21:16:54 +0100 (BST) X-Virus-Scanned: by amavisd-new using ClamAV at karnak.local Received: from karnak.local ([127.0.0.1]) by localhost (karnak.local [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URvyWM6luwK5 for ; Mon, 12 Sep 2011 21:16:52 +0100 (BST) Received: from karnak.local (localhost [127.0.0.1]) by karnak.local (Postfix) with ESMTP id 6D0FA3002 for ; Mon, 12 Sep 2011 21:16:52 +0100 (BST) Date: Mon, 12 Sep 2011 21:16:46 +0100 From: David W Noon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] udev + /usr Message-ID: <20110912211646.2cf11936@karnak.local> In-Reply-To: References: <20110912150248.GB3599@acm.acm> <2874055.6JTUjtRtEH@pc> <20110912171737.GC3599@acm.acm> Organization: Luton Operatic Society X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; i686-pc-linux-gnu) 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 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/3K+8vw=6PEoBZ_2gu+waeD1"; protocol="application/pgp-signature" X-Archives-Salt: X-Archives-Hash: 186581b1b93e2400ce3cc072430f74d2 --Sig_/3K+8vw=6PEoBZ_2gu+waeD1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 12 Sep 2011 15:00:49 -0400, Michael Mol wrote about Re: [gentoo-user] udev + /usr: > On Mon, Sep 12, 2011 at 2:37 PM, Canek Pel=C3=A1ez Vald=C3=A9s > wrote: [snip] > > And then you lose the flexibility. >=20 > Here's the chief problem with that argument...it's not just limited to > /usr. If you're going to say that a script can do whatever it wants, > and udev will make declarative statements about supported and > unsupported filesystem layouts to allow that to work, then you *must* > say that the entire filesystem be on the same partition as /, or that > one must use initramfs. >=20 > Because you can't know that a script won't depend on something under > /var. Or /opt. Or /home. And if if /home is excluded from this > must-be-available set, what makes it more special than /usr? If it's > OK to say "no script must access files under /home", then why isn't it > OK to say "no script must access files under /usr"? This gets back to what I wrote a few days back: put everything on / and call it C:. The real question is: how much flexibility do udev scripts actually need? My take is that udev scripts should only need to handle hardware interfaces presenting devices to the system, at least early in the bootstrap sequence. Later on, virtual devices, such as those presented by virtual machine managers to connect to the outside, need also to be handled. Then we have to consider what resources these scripts should be allowed to use. The main bugbear here is [semi-]interpretive scripting languages, such as Perl and Python. Quite simply, these should not be used. The external resources used by udev scripts should be statically linked, native object code binaries; this includes the system shells such as bash, zsh, etc. This has always been the case for hardware management code -- and with good reason: the greater the complexity of getting a piece of functionality running, the higher the likelihood that something is not yet available and it will fail. Yes, this is old; it's FORTRAN; it's COBOL; but it works reliably with minimal stress on the hardware. Now it becomes a matter of identifying those udev scripts that violate this idea and replacing them with better code. Logging script failures would be a first step in the right direction. However, given that many of the people coding these scripts don't bother checking return codes, this could be "asking for the moon on a stick". --=20 Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* dwnoon@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* --Sig_/3K+8vw=6PEoBZ_2gu+waeD1 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk5uaLQACgkQc9/LpQ70v4/SiACeOuGHIki/KzpOYuDLt1XCALR9 IBkAn1PPbX1NVpDvQebZatGl4t4yel/P =d4LB -----END PGP SIGNATURE----- --Sig_/3K+8vw=6PEoBZ_2gu+waeD1--