Re: [gentoo-user] udev + /usr

[David W Noon <dwnoon@ntlworld.com>]

[-- Attachment #1: Type: text/plain, Size: 2706 bytes --]

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áez Valdés
> <caneko@gmail.com> wrote:
[snip]
> > And then you lose the flexibility.
> 
> 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.
> 
> 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".
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]