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 > <can...@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] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* dwn...@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
signature.asc
Description: PGP signature
