From: Marc Ballarin <Ballarin.Marc@gmx.de>
To: "Giacomo A. Catenazzi" <cate@debian.org>
Cc: tonnerre@thundrix.ch, icampbell@arcom.com, greg@kroah.com,
md@Linux.IT, linux-kernel@vger.kernel.org
Subject: Re: udev is too slow creating devices
Date: Wed, 15 Sep 2004 18:51:16 +0200 [thread overview]
Message-ID: <20040915185116.24fca912.Ballarin.Marc@gmx.de> (raw)
In-Reply-To: <4148637F.9060706@debian.org>
On Wed, 15 Sep 2004 17:45:03 +0200
"Giacomo A. Catenazzi" <cate@debian.org> wrote:
> It is right.
> But an option --wait would be sufficient.
> This option will require modprobe to wait (with a timeout of
> x seconds) that hotplug event finish (so if device is created or
> not is no more a problem).
> Ideally this should be done modifing only hotplug and IMHO
> should be enabled by default.
At the moment th hotplug event finishes nothing is guaranteed. In fact,
the device node is never created at this point. All you know is that udev
will now *begin* to create the node. You don't know how long it will take
or if it will succeed at all.
As i understand, udev definitely has to be involved in this process. It
would need a way to inform modprobe of its state.
Maybe something like an udev state could be added. The script would
pass a cookie to modprobe, which would in turn pass it to the kernel (or
to udevd?), which would add it to the hotplug event. udev would then place
the cookie in a defined file that is checked by modprobe. If that cookie's
state is set to "done" modprobe would return and the script would
continue.
Example:
modprobe blah -c cookie-123
"cookie-123" is passed to the kernel and returned by all hotplug events
this modprobe triggers.
udev will then place something like "cookie-123=>processing" in
/dev/udev-state.
modprobe is still running and will poll this file until it contains
"cookie-123=>finished". When that happens modprobe will tell udevd to
remove this entry and return succesfully. If the timeout is reached
modprobe will return an error code instead.
(Of course, modprobe could handle the cookie generation internally.)
This sound complicated and requires changes in many places. Maybe there is
an easier solution.
Regards
next prev parent reply other threads:[~2004-09-15 16:43 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-14 18:33 udev is too slow creating devices Giacomo A. Catenazzi
2004-09-14 18:42 ` Greg KH
2004-09-14 19:21 ` Chris Meadors
2004-09-14 19:40 ` Chris Friesen
2004-09-14 19:52 ` Greg KH
2004-09-14 20:00 ` Chris Friesen
2004-09-14 20:43 ` Giacomo A. Catenazzi
2004-09-14 21:35 ` Greg KH
2004-09-14 21:45 ` Marco d'Itri
2004-09-14 21:51 ` Greg KH
2004-09-14 22:47 ` Andrea Arcangeli
2004-09-14 23:04 ` Greg KH
2004-09-14 23:20 ` Andrea Arcangeli
2004-09-14 23:34 ` Gianni Tedesco
2004-09-14 23:58 ` Andrea Arcangeli
2004-09-15 16:15 ` Greg KH
2004-09-15 19:21 ` Andrea Arcangeli
2004-09-15 22:09 ` Chris Friesen
2004-09-15 22:15 ` Andrea Arcangeli
2004-09-15 22:25 ` Greg KH
2004-09-15 22:23 ` Greg KH
2004-09-15 22:46 ` Andrea Arcangeli
2004-09-15 13:55 ` Giacomo A. Catenazzi
2004-09-15 14:36 ` Ian Campbell
2004-09-15 15:20 ` Tonnerre
2004-09-15 15:45 ` Giacomo A. Catenazzi
2004-09-15 16:12 ` Greg KH
2004-09-15 16:51 ` Marc Ballarin [this message]
2004-09-15 18:00 ` Greg KH
2004-09-19 16:51 ` Jon Masters
2004-09-19 18:53 ` Andreas Jellinghaus
2004-09-20 2:16 ` Alexander E. Patrakov
2004-09-17 8:06 ` Alexander E. Patrakov
2004-09-15 16:11 ` Greg KH
2004-09-15 16:09 ` Greg KH
2004-09-17 7:48 ` Alexander E. Patrakov
2004-09-14 22:03 ` Marc Ballarin
[not found] <http://lkml.org/lkml/2004/9/14/316@localhost.localdomain>
2004-09-14 20:30 ` Michael Thonke
[not found] <http://lkml.org/lkml/2004/9/15/119@localhost.localdomain>
2004-09-15 14:26 ` Michael Thonke
-- strict thread matches above, loose matches on Subject: below --
2004-09-18 19:25 Ihar 'Philips' Filipau
2004-09-18 21:24 ` Greg KH
2004-09-18 19:44 Ihar 'Philips' Filipau
2004-09-18 20:37 ` Marc Ballarin
2004-09-18 21:30 ` Greg KH
2004-09-19 0:06 ` Ihar 'Philips' Filipau
2004-09-19 0:41 ` Greg KH
2004-09-19 8:18 ` Ihar 'Philips' Filipau
2004-09-20 4:19 ` Greg KH
2004-09-19 4:38 ` Benjamin Herrenschmidt
2004-09-19 8:27 ` Ihar 'Philips' Filipau
2004-09-19 11:53 ` Alexander E. Patrakov
2004-09-19 17:32 ` Greg KH
2004-09-19 18:43 ` Grzegorz Kulewski
2004-09-20 4:11 ` Greg KH
2004-09-20 10:52 ` Jon Masters
2004-09-19 12:00 ` Marc Ballarin
2004-09-19 14:25 ` Ihar 'Philips' Filipau
2004-09-19 15:14 ` Marc Ballarin
2004-09-19 16:00 ` Alexander E. Patrakov
2004-09-19 17:11 ` Marc Ballarin
2004-09-19 17:30 ` Greg KH
2004-09-20 2:29 ` Alexander E. Patrakov
2004-09-20 16:17 ` Giacomo A. Catenazzi
2004-09-29 23:38 ` Randy.Dunlap
2004-09-29 23:53 ` Greg KH
2004-09-19 19:40 ` Ihar 'Philips' Filipau
2004-09-20 0:05 ` Kyle Moffett
2004-09-20 4:06 ` Greg KH
2004-09-20 8:54 ` Marc Ballarin
2004-09-20 0:03 ` Benjamin Herrenschmidt
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=20040915185116.24fca912.Ballarin.Marc@gmx.de \
--to=ballarin.marc@gmx.de \
--cc=cate@debian.org \
--cc=greg@kroah.com \
--cc=icampbell@arcom.com \
--cc=linux-kernel@vger.kernel.org \
--cc=md@Linux.IT \
--cc=tonnerre@thundrix.ch \
/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.