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@xxxxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part
