From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Sat, 08 Jan 2005 05:11:12 +0000 Subject: Re: Several fixes and enhancements for extented naming rules Message-Id: <1105161072.6847.14.camel@localhost.localdomain> List-Id: References: <41DEC1E2.3060806@idisys.iae.nsk.su> In-Reply-To: <41DEC1E2.3060806@idisys.iae.nsk.su> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.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