Re: Several fixes and enhancements for extented naming rules

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

On Mon, 2005-01-10 at 14:37 +0600, Alexey Morozov wrote:
> Kay Sievers пишет:
> >>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).

You still have the same races as the current %e used outside of udevstart.

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

No, only the enumeration part of namedev should be taken out, as in our
current model of independent running event processes, we can't really do
this inside of udev.

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

No, it is just an idea and was mainly a question, what you/others think.

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

Right, the callout could do this kind of serialization.

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

What may be the reason for reentrancy here. udevd serialized the
execution of events with the same devpath.

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

I don't know what's the best architecture for that kind of counters, but
I don't think that we should replace our current udevdb with something
like that.

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

I can't reproduce this. The partition events are delayed by udevd until
the main block device event has exited. It works on my box.

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

Ok, fine. Is it possible to do the same without changing our in-tree
libsysfs version?

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