From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: waiting for an unknown set of udev /dev entries to complete
Date: Tue, 22 Nov 2005 23:13:06 +0000 [thread overview]
Message-ID: <20051122231306.GA21094@vrfy.org> (raw)
In-Reply-To: <20051118223045.GA28401@us.ibm.com>
On Mon, Nov 21, 2005 at 01:01:54AM +0100, Marco d'Itri wrote:
> On Nov 21, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
> > > I still see a problem with this design: there is a period (which may be
> > > easy to hit if the udevd is spawning the maximum allowed number of
> > > children), between when events are sent to udevd and when it starts
> > > processing them, when the on-disk queue is empty.
> > It's the received event queue, which is exported, not the processes
> > currently running. What problem do you see related to the maximum number
> > of childs?
> Nevermind, this makes the race much shorter but it's still there.
>
> > There is still a small theorethical window between the module load
> > and the first event for a device created by that module, but it's unlikely
> > to hit that and it should be easy to work around that, if necessary.
> Yes, this is what I meant (in the context of boot-time events synthesis)
> and I do not like taking this risk.
Scott sent a nice patch to remove the /dev/.udev.queue directory if it's
empty. That makes it pretty easy to work around this:
start udevd
mkdir -p /dev/.udev/queue
trigger uevent's in /sys
while test -d /dev/.udev/queue; do sleep 0.1; done
The last event will just rmdir() the created queue directory.
Kay
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_idv28&alloc_id\x16845&op=click
_______________________________________________
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
next prev parent reply other threads:[~2005-11-22 23:13 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-18 22:30 waiting for an unknown set of udev /dev entries to complete Patrick Mansfield
2005-11-20 6:03 ` Kay Sievers
2005-11-20 17:25 ` Patrick Mansfield
2005-11-20 18:23 ` Kay Sievers
2005-11-20 20:10 ` Pozsar Balazs
2005-11-20 20:23 ` Marco d'Itri
2005-11-20 23:32 ` Kay Sievers
2005-11-20 23:53 ` Kay Sievers
2005-11-21 0:01 ` Marco d'Itri
2005-11-22 23:13 ` Kay Sievers [this message]
2005-11-23 8:26 ` Scott James Remnant
2005-11-23 10:54 ` Pozsar Balazs
2005-11-23 16:27 ` Harald Hoyer
2005-11-23 16:50 ` Kay Sievers
2005-11-23 17:25 ` Pozsar Balazs
2005-11-23 17:46 ` Kay Sievers
2005-11-23 18:16 ` Pozsar Balazs
2005-11-23 18:39 ` Kay Sievers
2005-11-23 21:33 ` Patrick Mansfield
2005-11-28 22:09 ` Pozsar Balazs
2005-11-29 10:44 ` Kay Sievers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051122231306.GA21094@vrfy.org \
--to=kay.sievers@vrfy.org \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.