mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Marc Ballarin <Ballarin.Marc@gmx.de>
To: "Ihar 'Philips' Filipau" <filia@softhome.net>
Cc: benh@kernel.crashing.org, greg@kroah.com, linux-kernel@vger.kernel.org
Subject: Re: udev is too slow creating devices
Date: Sun, 19 Sep 2004 17:14:56 +0200	[thread overview]
Message-ID: <20040919171456.0c749cf8.Ballarin.Marc@gmx.de> (raw)
In-Reply-To: <414D96EF.6030302@softhome.net>

On Sun, 19 Sep 2004 16:25:51 +0200
Ihar 'Philips' Filipau <filia@softhome.net> wrote:

> 
>    Well, can then anyone explain by which mean (black magic?) kernel 
> mounts root file system? block device might appear any time, file system
> might take ages to load.

The kernel doesn't use /dev.
Why do you think mounting the root device is such a "frail" process?
The kernel blindly ties all known filesystem on the specified device.
If the user specifies a wrong root device, or the device is broken or the
filesystem corrupted or unknown the kernel will panic.
The reason this is so is, that nothing else can be done. Userspace,
however, has more possibilities.

> 
>    People, you must learn doing abstractions carefully. If device is 
> hard-wired - user *will* expect (as kernel itself does) that it is 
> available all the time after modprobe'ing driver.

It is available as long as the device node is present. udev tells you (in
dev.d) when this is the case. If the device is hardwired (from a user's
point of view) the device node will be created early dring boot-up. If
this happens, udev will notify the scripts in dev.d.

Instead of:
modprobe ide-cd && mount /dev/hdc /mnt/cdrom
in /etc/init.d/your-script

you would now do:
if [ ACTION="add" ] && [ DEVNAME="/dev/hdc" ]; then
	mount /dev/hdc /mnt/cdrom
fi
in /etc/dev.d/default/your-script.dev

This is even more reliable than the first solution on a static /dev,
since loading the driver might fail at any point *after* modprobe
returns.
For example, modprobe ide-cd will succeed even when no CD-ROMs are
present. The old script would break in this case, the new one wouldn't be
called at all.

Error reporting is very difficult. How should the kernel know what the
driver is supposed to do?
Obvious errors likes Oopses or I/O errors *could* be reported by hotplug.
(ACTION="error", DEVNAME="module-name" ???)
Anything else is impossible.

You just have to adopt your approach to device handling. Currently you
*assume* that after a succesfull modprobe the device nodes are available
(this was never true, however).
With hotplug/udev you *know* that the device node is available when your
script in dev.d is called with the appropriate environment variables.

Regards

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

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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
  -- 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=20040919171456.0c749cf8.Ballarin.Marc@gmx.de \
    --to=ballarin.marc@gmx.de \
    --cc=benh@kernel.crashing.org \
    --cc=filia@softhome.net \
    --cc=greg@kroah.com \
    --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

all inboxes | Powered by JetHome®