linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Dake <sdake@mvista.com>
To: Linus Torvalds <torvalds@transmeta.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:10:23 -0700	[thread overview]
Message-ID: <3EF250EF.1010802@mvista.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0306191700010.1987-100000@home.transmeta.com>



Linus Torvalds wrote:

>On Thu, 19 Jun 2003, Steven Dake wrote:
>  
>
>>A serialization methodology can be built on /sbin/hotplug, but it has 
>>all of the problems that Linus previously talked about for a kernel 
>>event queue.  The difference is that the problem is moved to userland.
>>    
>>
>
>Having event ordering is a trivial matter, and I'm not against adding a
>sequence number to /sbin/hotplug as part of the environment, for example. 
>
>What I worry about is the situation where one big deamon handles 
>everything, which makes it impossible to "hook in" to the thing without 
>understanding the one big thing.
>
>The thing that makes /sbin/hotplug so wonderful is that it's stateless,
>and if you want to hook into it, it's absolutely _trivial_.  Look at the 
>default script there in redhat-9 for example, and it's obvious how to hook 
>up to certain events etc.
>
>And why do people care about serialization anyway? Really? The whole 
>notion is ludicrous. /sbin/hotplug _shouldn't_ be serialized. 
>Serialization is bad. You should look at whatever problems you have with 
>it now, and ask yourself whether maybe it should be done some other way 
>entirely.
>  
>
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 occurance does happen much more often then you might think.  When 
changing disk partitions, for example, items are removed and then added 
several times before the devices are finally instantiated.

Definately to be avoided.

Thanks
-steve

>		Linus
>
>
>
>  
>


  reply	other threads:[~2003-06-19 23:56 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 [this message]
2003-06-20  0:43           ` Linus Torvalds
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=3EF250EF.1010802@mvista.com \
    --to=sdake@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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).