Re: default udev rules

[Scott James Remnant <scott@canonical.com>]

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

On Mon, 2008-08-11 at 13:37 -0400, David Zeuthen wrote:

> On Mon, 2008-08-11 at 16:42 +0100, Scott James Remnant wrote:
> > But surely that means cases where we need NAME= rules are now better
> > fixed by fixing the kernel to give it the right name in the first place?
> 
> The kernel name is most of the time useless - it's simply just a damn
> cookie. FWIW, my view is that any application depending on the kernel
> name is always almost broken (except for singleton devices
> like /dev/mapper/control etc.) except for when the user hasn't
> configured what device to use (e.g. use the first webcam, the first
> optical drive etc. etc.).
> 
> So this is why udev ships code (not user configurable settings!) in udev
> rules for persistent naming. Unfortunately we don't have persistent
> names for everything (and for some things it of course won't make
> sense). Send patches.
> 
My problem with this is that it means udev has to execute code to
construct that persistent name, even when it's static.

And since udev can't do much in the way of intelligent string
manipulation itself, we have to fork and exec a shell or some other
binary to do it for us.

Which is kinda expensive.

Especially when the kernel had all the bits, and could have just set the
default static name in the first place.


If we're all going to agree on a fixed naming scheme, the old argument
that the kernel didn't set such policy is moot.  The kernel should agree
with our defaults, otherwise we're wasting time, cycles and effort
converting the kernel defaults into our own defaults.  Every damned
time.

(I have similar arguments every time someone asks for a modprobe.d
"option" line - if it should be the default, then patch the module so it
*is* the default)

Scott
-- 
Scott James Remnant
scott@canonical.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]