Re: Several fixes and enhancements for extented naming rules

[Kay Sievers <kay.sievers@vrfy.org>]

On Fri, 2005-01-07 at 23:07 +0600, Alexey Morozov wrote:
> Playing with udev naming rules, I notices that existing '%e' macro can't 
> be really used in several cases (important at least for me).

Please explain the several cases!

> This 
> 'extended' macro is quite useful if e.g. we try to build nice 
> "human-friendly" device naming scheme and strictly separate devices 
> names and permissions assignment (to rules.d/* and permissions.d/* 
> respectively)

permissions.d/ is gone. We have the permissions in the rules file form
the next version on.

> First of all, if one tries to give several names to a device (say, 
> create additional symlinks for a CD-RW device like /dev/cdrom, 
> /dev/cdwriter) udev ends up w/ errors.

What kind of errors? Please explain!

> Also I really doubt if %e w/ existing rules processing code can be used 
> in constructions like /dev/discs/disc%e/disc and other devfs-like naming 
> schemes.

Yes, this doesn't work, but the scripts can do this, right?

> So I decided to patch it a bit to achieve such functionality. You can 
> find this patch in the attachment.
> 
> Also I'd like to have another macro. While %e is substituted w/ nothing for
> 'mydevice%e' if /dev/mydevice doesn't exist yet, this new macro always 
> substituted w/ a non-negative number. I called it %N, but in fact these 
> names can be changed in future. This is particularly useful for names 
> like /dev/discs/disc%N/{.....} and allows to simplify devfs-like naming 
> scripts.

Is there really the need to move this into udev? What is the limitation
of the scripts?

> Also I made a patch for (optional) compilation of udev w/ a system-wide 
> installed sysfs libraries. I'm not sure it's a good idea 'for everyone' 
> but if we anyway have libsysfs and it's fresh enough to seamlessly work 
> w/ udev, I don't see any reasons to have a separate copy right in udev 
> source tree. Probably I make a mistake, but it worked /for me/ so far, 
> and hey, it's optional anyway.

Does this work with the klibc build, which cannot use the system
installed version of sysfs?

Kay



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel