Re: Several fixes and enhancements for extented naming rules parameters

[Alexey Morozov <alex-hp@idisys.iae.nsk.su>]

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