public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Gianni Tedesco <gianni@scaramanga.co.uk>
To: Andrea Arcangeli <andrea@novell.com>
Cc: Greg KH <greg@kroah.com>, "Marco d'Itri" <md@Linux.IT>,
	"Giacomo A. Catenazzi" <cate@pixelized.ch>,
	linux-kernel@vger.kernel.org
Subject: Re: udev is too slow creating devices
Date: Wed, 15 Sep 2004 00:34:40 +0100	[thread overview]
Message-ID: <1095204880.8493.153.camel@sherbert> (raw)
In-Reply-To: <20040914232011.GG3365@dualathlon.random>

On Wed, 2004-09-15 at 01:20 +0200, Andrea Arcangeli wrote:
> On Tue, Sep 14, 2004 at 04:04:09PM -0700, Greg KH wrote:
> > On Wed, Sep 15, 2004 at 12:47:31AM +0200, Andrea Arcangeli wrote:
> > > On Tue, Sep 14, 2004 at 02:51:22PM -0700, Greg KH wrote:
> > > > True, so sit and spin and sleep until you see the device node.  That's
> > > > how a number of distros have fixed the fsck startup issue.
> > > 
> > > that's more a band-aid than a fix (I can imagine a userspace hang if the
> > > device isn't created for whatever reason), if there's no way to do
> > > better than this if you've to run fsck (or if it's not the best to run
> > > the fsck inside the dev.d scripts), then probably this needs better
> > > fixing. is such a big problem to execute a sys_wait4 to wait the udev
> > > userspace to return before returning from the insmod syscall?
> > 
> > But how do you know what to wait for?
> 
> the kernel sure can know about it, by passing a waitqueue into the
> registration routine and calling wake_up once the discovery is over.
> 
> > Sitting and waiting is a band-aid, I agree.  That's why we created the
> > /etc/dev.d/ notifier system to fix this issue (that is there for systems
> > that don't even use udev.)
> 
> if the fsck can run from there ok, if for some reason it's not feasible
> to run it from there (like if it would create a bus congestion by
> running all the fsck in parallel if you attach multiple devices at the
> same time), and/or you need some other seriaization, then probably
> having a way to run things serially without a
> spin-and-sleep-and-risk-to-hang could be needed. I guess in the worst
> case one could serialize things by using file locking in /var/run
> and by creating an API between the dev.d and the init.d scripts, is that
> how the long term is supposed to work?
> 
> So it's more a question if the current interface is complete for all
> usages, and if the fsck spin-and-sleep is just a temporary band-aid, or
> if the spin-and-sleep is supposed to last longer than a few month
> release cycle.

Surely fsck can be done on top of /etc/dev.d/ by just writing to a FIFO?
That'll serialize up the fsck caller...

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D


  reply	other threads:[~2004-09-14 23:36 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 [this message]
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
     [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=1095204880.8493.153.camel@sherbert \
    --to=gianni@scaramanga.co.uk \
    --cc=andrea@novell.com \
    --cc=cate@pixelized.ch \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=md@Linux.IT \
    /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