public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Alexander E. Patrakov" <patrakov@ums.usu.ru>
To: linux-kernel@vger.kernel.org
Subject: Re: udev is too slow creating devices
Date: Fri, 17 Sep 2004 14:06:28 +0600	[thread overview]
Message-ID: <cie5th$c57$2@sea.gmane.org> (raw)
In-Reply-To: <20040915185116.24fca912.Ballarin.Marc@gmx.de>

Marc Ballarin wrote:
> 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.

Yes, there is, and it is a purely userspace one. Instead of waiting for 
those hotplug events, synthetize their duplicates in the "modprobe" 
binary, pass directly to udev, and wait for these duplicates.

-- 
Alexander E. Patrakov


  parent reply	other threads:[~2004-09-17  8:06 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
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 [this message]
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='cie5th$c57$2@sea.gmane.org' \
    --to=patrakov@ums.usu.ru \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox