All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Ballarin <Ballarin.Marc@gmx.de>
To: "Alexander E. Patrakov" <patrakov@ums.usu.ru>
Cc: linux-kernel@vger.kernel.org
Subject: Re: udev is too slow creating devices
Date: Sun, 19 Sep 2004 19:11:29 +0200	[thread overview]
Message-ID: <20040919191129.6f06293d.Ballarin.Marc@gmx.de> (raw)
In-Reply-To: <cikaf1$e60$1@sea.gmane.org>

On Sun, 19 Sep 2004 22:00:52 +0600
"Alexander E. Patrakov" <patrakov@ums.usu.ru> wrote:

> 
> OK. The fact is that, when mounting the root filesystem, the kernel can 
> (?) definitely say "there is no such device, and it's useless to wait 
> for it--so I panic". Is it possible to duplicate this logic in the case 
> with udev and modprobe? If so, it should be built into a common place 
> (either the kernel or into modprobe), but not into all apps.

Well, once  the system is running, the device might appear any time, so
waiting is hardly useless then.

In the past you did modprobe and afterwards tried to access the device. If
this succeeded, the device was created successfully, if not, something
went wrong, and your script returned an error code.
This approach has some problems.
The device is plugged in later on: "su" to root, re-run script. Not nice.
The script doesn't check properly for later errors: something breaks.

Now, the device is either autodetected or - when this is not possible
("legacy" devices) you have to modprobe manually.
If this succeeds, you are informed in dev.d. If it fails you are
"informed" by not being called in dev.d.

If I understand correctly, you wish do modprobe for a legacy device and
then know if this succeeded completely.
Simply choose a state-file in /var and write something like "not detected"
inside. Then do modprobe.
The other part of your script will wait in dev.d for the event. If it
arrives, the script will change the state file to "found" and do its work.
So, as long as the state is "not detected" you treat the device as not
present - just as if your old, synchronous script had returned an error
code. The advantage is, that if the device appears later on everything
will work automatically.

> 
> Then the "char-major" aliases were always broken, do I understand 
> correctly? Once we realize that, isn't it the time to mark the 
> "Automatic kernel module loading" in the kernel configuration as BROKEN 
> or OBSOLETE?

IIRC this feature is intended primarily for loadable kernel features and
pseudo devices, not "real" device drivers.

> 
> Yes. Now we have a lot of short scriptlets under /etc/dev.d. But I don't
> yet see how these scriptlets interact with each other.

You could use some state file if hotplug messages aren't enough, as
described above.

mfg

  reply	other threads:[~2004-09-19 17:05 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-18 19:44 udev is too slow creating devices 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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2004-09-18 19:25 Ihar 'Philips' Filipau
2004-09-18 21:24 ` Greg KH
     [not found] <http://lkml.org/lkml/2004/9/15/119@localhost.localdomain>
2004-09-15 14:26 ` Michael Thonke
     [not found] <http://lkml.org/lkml/2004/9/14/316@localhost.localdomain>
2004-09-14 20:30 ` Michael Thonke
2004-09-14 18:33 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
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

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=20040919191129.6f06293d.Ballarin.Marc@gmx.de \
    --to=ballarin.marc@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patrakov@ums.usu.ru \
    /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.