Re: default udev rules

[Greg KH <greg@kroah.com>]

On Mon, Aug 11, 2008 at 07:00:59PM +0100, Scott James Remnant wrote:
> 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.

expensive to whom?  Have you really timed it?  Is this a boot time speed
issue?  or a "oh no, I had to wait 50ms after my device was plugged in
before I could use it!" type thing?

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

Examples please, I really don't know how the kernel can do this for the
things that we create persistant names for today.  Do you?

> 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)

Patches for the kernel are always accepted.

thanks,

greg k-h