Re: Several fixes and enhancements for extented naming

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

On Sat, 2005-01-08 at 14:34 +0600, Alexey Morozov wrote:
> Kay Sievers writes:
> >On Fri, 2005-01-07 at 23:07 +0600, Alexey Morozov wrote:
> >>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.

A separate rule with only one SYMLINK works. That's not perfect, but see
later in this mail.

> >>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').

I've never heard any complains about the speed of udev. :)

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

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.

> 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 are no plans. The only current workaround is to use a different
filesystem. 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...

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

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.

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

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.

The sources of the in-tree libsysfs should not be changed, it better
matches the upstream version. Otherwise it would be nice to be able to
offer this switch.

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