Re: [PATCH] udev enhancements to use kernel event queue

[Werner Almesberger]

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         [e-mail] /
/_http://www.almesberger.net/____________________________________________/