linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@transmeta.com>
To: Steven Dake <sdake@mvista.com>
Cc: Werner Almesberger <wa@almesberger.net>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] udev enhancements to use kernel event queue
Date: Thu, 19 Jun 2003 17:43:26 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.44.0306191717120.1987-100000@home.transmeta.com> (raw)
In-Reply-To: <3EF250EF.1010802@mvista.com>


On Thu, 19 Jun 2003, Steven Dake wrote:
>
> Serialization is important for the case of a device state change 
> occuring rapidly.  An example is a device add and then remove, which 
> results in (if out of order) the add occuring after the remove, leaving 
> a dead device node in the filesystem.  This is tolerable.  What isn't as 
> tolerable is a remove and then an add, where the add occurs out of order 
> first.  In this case, a device node should exist on the filesystem, but 
> instead doesn't because the remove has come along and removed it.

This still isn't a global serialization thing, though. For example,
there's no reason _another_ device should be serialized with the disk
discovery.

And there are lots and lots of reasons why they should not EVER be
serialized, especially since full serialization (like through a shared
event deamon) results is _serious_ problems if one of the events end up
being a slow thing that needs to query and/or spin up hardware.

In other words, once you start talking about device nodes, you really want
to handle the serialization on a per-node basis. Having some kind of 
kernel support for that is quite possible a good idea, but care should be 
taken that non-dependent events shouldn't be serialized.

An easy way to do partial serialization is something like this:

 - each "call_usermodehelper()" gets associated with two numbers: the 
   "class number" and the "sequence number within a class". We keep track 
   of outstanding usermodehelpers.

   Add the class and sequence number to the environment of the hotplug 
   execution so that the user-mode hotplug code can query them.

 - we add a simple interface to allow a user mode helper to ask the kernel 
   to "please wait until class X has no pending sequence numbers smaller 
   than Y"

See what I'm aiming at? The class numbers shouldn't have any particular
meaning, they're just a random number (it might be the bus number of the
device that hotplugged, for example). But this allows a hotplug thing to
say "if there are other outstanding hotplug things in my class that were
started before me, wait here".

		Linus


  reply	other threads:[~2003-06-20  0:29 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-12 19:10 [PATCH] udev enhancements to use kernel event queue Steven Dake
2003-06-12 21:47 ` Patrick Mochel
2003-06-13 16:31   ` Steven Dake
2003-06-13 17:06     ` Patrick Mochel
2003-06-12 21:47 ` Greg KH
2003-06-12 22:03   ` Andrew Morton
2003-06-12 22:50     ` Greg KH
2003-06-12 22:51       ` Andrew Morton
2003-06-12 23:02         ` Greg KH
2003-06-12 23:09           ` Greg KH
2003-06-12 23:14             ` Patrick Mochel
2003-06-12 23:16             ` Robert Love
2003-06-12 23:25               ` Greg KH
2003-06-13 20:01                 ` Oliver Neukum
2003-06-18 22:59                   ` Greg KH
2003-06-19  0:12                     ` Kevin P. Fleming
2003-06-19  0:20                       ` Greg KH
2003-06-19  0:42                         ` Kevin P. Fleming
2003-06-19  0:51                           ` Greg KH
2003-06-19  0:25                       ` Andrew Morton
2003-06-19  6:27                       ` Oliver Neukum
2003-06-12 23:25               ` Patrick Mochel
2003-06-12 23:29                 ` Robert Love
2003-06-12 23:32                   ` Greg KH
2003-06-12 23:34                   ` Patrick Mochel
2003-06-12 23:40                     ` Paul Mackerras
2003-06-12 23:50                       ` Robert Love
2003-06-13 12:44                         ` Richard B. Johnson
2003-06-13 12:54                           ` Olivier Galibert
2003-06-12 23:52                       ` Patrick Mochel
2003-06-13  8:41                       ` Alan Cox
2003-06-13 11:00                         ` Paul Mackerras
2003-06-13 11:07                           ` Herbert Xu
2003-06-13 13:31                           ` Alan Cox
2003-06-13 19:57                             ` Joe Korty
2003-06-13 21:10                               ` Alan Cox
2003-06-13 11:17                       ` David Schwartz
2003-06-13 15:44                         ` Davide Libenzi
2003-06-12 23:42                     ` Robert Love
2003-06-12 23:45                     ` Davide Libenzi
2003-06-12 23:05       ` Robert Love
2003-06-19 19:51       ` Werner Almesberger
2003-06-26 12:17         ` Tommi Virtanen
2003-06-26 14:35           ` Werner Almesberger
2003-06-13  8:40     ` Alan Cox
2003-06-13  9:14       ` Olivier Galibert
2003-06-19 20:53         ` Werner Almesberger
2003-06-13 16:05       ` Steven Dake
2003-06-13 16:32       ` Greg KH
2003-06-13 15:51   ` Steven Dake
2003-06-13 16:41     ` Patrick Mochel
2003-06-13 16:42     ` Greg KH
2003-06-13 17:17       ` Chris Friesen
2003-06-12 22:27 ` Oliver Neukum
2003-06-13 16:03   ` Steven Dake
2003-06-13 16:50     ` Patrick Mochel
2003-06-13 17:10       ` Steven Dake
2003-06-13 18:26         ` Greg KH
2003-06-13 19:02         ` Patrick Mansfield
2003-06-13 17:32     ` Oliver Neukum
2003-06-13 18:23     ` Greg KH
2003-06-13 18:24     ` Greg KH
2003-06-13  7:17 ` Christoph Hellwig
2003-06-13 18:06 ` Linus Torvalds
2003-06-19 23:32   ` Werner Almesberger
2003-06-19 23:42     ` Steven Dake
2003-06-20  0:05       ` Linus Torvalds
2003-06-20  0:10         ` Steven Dake
2003-06-20  0:43           ` Linus Torvalds [this message]
2003-06-20  2:26             ` Werner Almesberger
2003-06-20 17:03             ` Steven Dake
2003-06-20 17:18               ` Patrick Mochel
2003-06-14  6:36 John Bradford

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=Pine.LNX.4.44.0306191717120.1987-100000@home.transmeta.com \
    --to=torvalds@transmeta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sdake@mvista.com \
    --cc=wa@almesberger.net \
    /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;
as well as URLs for NNTP newsgroup(s).