From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey Morozov Date: Sat, 08 Jan 2005 08:34:39 +0000 Subject: Re: Several fixes and enhancements for extented naming rules parameters Message-Id: <41DF9B1F.1010300@idisys.iae.nsk.su> 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 Kay Sievers writes: >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! > > Well, I tried to describe them below in that letter, right? I can show you entire contents of /dev on my workstation. >>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. > > Hmm, well, maybe it's a good idea, but I doubt it can increase maintainability of udev setups. But perhaps I'm wrong, I need to think a bit about possible consequences and undestand how things change in this case. >>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! > > Sure. Existing 'if such a name already assigned by udev to a device' code works poorly if e.g. _several_ symlinks are to be considered. It simply doesn't split entire string SYMLINK="a_name1 another_name2 ... generic_name%e" into tokens and therefore can't really check if corresponding /dev/generic_name* etc are already assigned to some devices. You may try it yourself. >>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? > > Please see the answer below. >>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? > > Speed. Complexity. As you may notice, I mostly re-used existing udev code in these patches. W/ a "pure scripts" solution I would had to do all the things from scratch. I looked at existing udev supporting scripts (from debian, gentoo and Mdk) and found that they works really harder than my code to achieve corresponding or even lesser level of functionality (at least in implementing equivalents of those 'extended attributes' like '%e'). Sure namedev stuff can probably be taken out of main udev binary. But in any case a stateless script which has to calculate everything it needs to form a name each time it's launched, well, that script will be more complex and slow than a solution w/ a binary and pre-built database in a convenient format. BTW, my current /dev/.udevdb eats ~2.8Mb of space (/dev is on tmpfs) on an ordinary workstation w/o much hardware plugged in. Is that intended result? ;-) Are there plans to change its format? Now it's a lot, ~700 files, each 40-50 bytes long. I guess smth like a berkeley db will be more appropriate in this case, but I'm not sure if it's a good idea to take even statically linked db1 to Early User Space stuff. Maybe there're some other workarounds for the problem? There's another little problem to be considered. E.g. I noticed that sda1 creation event for my flash drive often comes when entire sda event hasn't been processed completely yet. So we have to deal w/ such concurrency, and I really believe that C provides better tools and techniques for that than bash-programming. >>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? > > Well, it's just a linker flag. Instead of explicitly link libsysfs/sysfs.a, it can pass to the linker anything from $(SYS_SYSFS). It can be -lsysfs, or just a /usr/lib/libsysfs.a if one wants. So the answer is yes, it works if we build udev on a system w/ an appropriate libsysfs installed. Yours faithfully, Alexey Morozov ------------------------------------------------------- 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