From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Mon, 10 Jan 2005 12:03:59 +0000 Subject: Re: Several fixes and enhancements for extented naming rules Message-Id: <1105358639.6565.72.camel@localhost.localdomain> 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="utf-8" Content-Transfer-Encoding: 8bit To: linux-hotplug@vger.kernel.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= 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