Re: Several fixes and enhancements for extented naming rules parameters

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

Kay Sievers пишет:

>>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.
>>    
>>
>>Speed. Complexity. As you may notice, I mostly re-used existing udev 
>>code in these patches. 
>>    
>>
>I've never heard any complains about the speed of udev. :)
>  
>
I've heard indeed. Particularly about the speed of udevstart ;-). But 
the main worries about complexity.

>  
>
>>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.
>>    
>>
>
>Well, the problem is that the %e is just a dirty hack to provide compatibility
>symlinks. It works only in the udevstart case. If driven by hotplug events,
>  
>
Hmm, with my patches it works everywhere ;-). Trust me ;-). At least in 
'real userlevel' (haven't played w/ early userland stuff yet).

>it's slippery cause of the concurrently running processes for each device.
>It happens, that you get the same enumeration number for multiple
>devices. I don't feel comfortable to move more of this conceptually broken stuff
>into udev.
>  
>
Well, it's understandable.

>How about creating _and_ supporting a callout in the extras/ folder, that is
>able to store and retrieve information from its own database stored in a
>dotfile in /dev? devfs scripts can use that extra and it may use a file lock to
>serialize the events. It is still not guaranteed that the enum is in the event
>order, but doubles may be avoided this way. Also the stupid reverse lookup of the
>udevdb is avoided this way, which needs to read all db-files every time again.
>  
>
> The db operations need to be completely lockless. We already
>have had a single file database but some setups got several hundred
>processes concurrently locking this file and waiting for a slot to write
>to and it failed badly...
>  
>
Well, as I understand you propose [me] to take away [most of] namedev.* 
and udev_db.* stuff out of main udev binary sources and create an 
'user-level' (well, even more user-level :-)) utility, which does 
basically the same upon a request from scrips, right? Are there any 
works in that direction already? Are there some sort of strict 
specifications for the task?

As I can see it now, any usage of 'extended substs' like '%e' will cause 
a need in some sort of serialized/synchronous operations (in case two 
hotplug events got delivered in the same time), so I just can't see a 
solution w/o any locks at all. Sure these locks can be, well, cheap or 
lightweight, 'row-locks' etc, but all my previous experience tells me 
there must be some serialization anyway. BTW, existing udevdb stuff 
seems not to be a reentrant safe at least in the 
udev_db_get_device_byname part.

Maybe this new utility should act like a small daemon listening a 
[unix-domain] socket (a FIFO? hmm) for incoming name pattern requests 
and responding w/ substitutions performed. This way we can avoid 
re-parsing device DB on each request and serialize things properly so 
parallel devices creation events won't be blocked for a too long time. 
I'm not sure about availability of corresponding kernel functionality in 
early userland stages. We also can avoid 'on disk' DB if needed.


>>BTW, my current /dev/.udevdb eats ~2.8Mb of space (/dev is on tmpfs) on 
>>    
>>
>There are no plans. The only current workaround is to use a different
>filesystem.
>
Umm... tmpfs already has useful hacks like this one: 
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0411.0/1568.html

I doubt it's worth to intend /dev functionality to an 'adult' filesystem 
w/ tail packing, resident files and other super-cool and awesome features.

>>E.g. I noticed that sda1 creation event for my flash drive often comes when entire sda event 
>>hasn't been processed completely yet.
>>    
>>
>This should not happen. sda1 is a child of sda and these events are
>serialized from version 049 on. sda, sdb, ... still run in parallel.
>  
>
Well, I noticed that partition node creation script is running when the 
entire device node hasn't been created yet. I even had to put some ugly 
polling into drive-names.sh (lines 60-73), which solved the problem. 
Probably, it's not an udev, but e.g. tmpfs fault, but anyway it exists 
(at least on my 2.6.9 w/ corresponding Con Kolivas patchset applied).

>>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.
>>    
>>
>
>We sometimes make changes to the in-tree version and therefore we don't
>want to officially support a system wide version. So the system-wide
>compile must be the optional one which is only linked if the user asks
>for it.
>  
>
It's completely optional. If you don't provide SYS_SYSFS=<smth suitable 
to linker> flag as a make parameter, then it goes just as w/o any patch.

That's extracts from udev.spec I use to build it for my distro:

...
# (Near the beginning of the spec):
# whether we want to use system-wide sysfs or udev local copy
# Note udev-0.50 requires a recent version of sysfs,
%def_with system_sysfs
...
%if_with system_sysfs
BuildRequires: libsysfs-devel > 1.2.0-alt2
%endif
...
%make_build \
         udevdir=/dev \
...
%if_with system_sysfs
        SYS_SYSFS=-lsysfs \
%endif
...



-------------------------------------------------------
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