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

[Steven Dake <sdake@mvista.com>]

Linus Torvalds wrote:

>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".
>
>  
>
A class number is an excellent idea, and could have potential 
performance gains.  I thought of making such a patch, but expected it 
would be rejected since it is necessarily required and would require 
changes to significant sections of the kernel (to add the class to each 
object type).

Have any better ideas for an implementation that doesn't touch so many 
sections of the kernel?

>		Linus
>
>
>
>  
>