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

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

Yes, that sounds a lot better. Let's hope nobody discovers such
a reason ...

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

That would work. It's in fact a per-class message queue, in which
sleeping processes play the role of messages ;-)

I thought a bit about what else one could do with this interface:

 - if you need loss/error handling, and are willing to keep one
   bit of information for each such class in the kernel, the it
   could register whether processing the previous event has
   succeeded, i.e. whether the kernel was able to launch a helper,
   and whether that helper has returned with exit status 0. This
   bit could be returned by the synchronization call.

 - in principle it would now be easy, and in many ways cleaner and
   more efficient, to turn this into a per-class event demon, with
   a "real" event queue. The problem is that you'd probably still
   want classes that are not serialized, and the kernel wouldn't
   know whether a given class needs serialization before
   /sbin/hotplug has run for a while. Neiter configuring class
   behaviour nor adding an "asychronous class" look particularly
   attractive to me.

   Too bad. A synchronous /sbin/hotplug as follows would certainly
   be nice, e.g. assuming that in each class only one event type
   can occur:

   #!/bin/sh
   agent=$1
   read event
   set $event
   <... normal /sbin/hotplug code ...>

   or, the high-performance variant:

   #!/bin/sh
   exec /etc/hotplug/$1.agent

   #!/bin/sh
   <... do really expensive initialization ...>
   while read event; do
       set $event
       <... normal /etc/hotplug/*.agent code ...>
   done

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

  reply	other threads:[~2003-06-20  2:13 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
2003-06-20  2:26             ` Werner Almesberger [this message]
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=20030619232654.F6248@almesberger.net \
    --to=wa@almesberger.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sdake@mvista.com \
    --cc=torvalds@transmeta.com \
    /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).