Re: [ANNOUNCE] udev 0.1 release

[Steven Dake]

Greg KH wrote:

>On Fri, Apr 11, 2003 at 03:09:33PM -0700, Andrew Morton wrote:
>  
>
>>Steven Dake <[e-mail]> wrote:
>>    
>>
>>>A much better solution could be had by select()ing on a filehandle 
>>>indicating when a new hotswap event is ready to be processed.  No races, 
>>>no security issues, no performance issues.
>>>      
>>>
>>I must say that I've always felt this to be a better approach than the
>>/sbin/hotplug callout.
>>
>>Apart from the performance issue, it means that the kernel can buffer the
>>"insertion" events which happen at boot-time discovery until the userspace
>>handler attaches itself.
>>    
>>
>
>But how many events to we buffer?  When do we start to throw them away?
>Fun policy decisions that we don't have to worry about in the current
>scheme.
>  
>
There are all kinds of policy decisions about how many of something is 
in the kernel...  For example, file descriptors, selectable file 
descriptors, etc.

It would be simple to determine how many events should be saved by even 
the most complex application or event counts could be configurable.  The 
issue of dropping events only matters for startup, since anything later 
is likely not to have as many new devices as a startup sequence might...

>Also, what's the format of the kernel->user interface.  Today with
>/sbin/hotplug it's a very simple, and easily changed interaction.  Using
>a event reading mechanism lends itself to binary interfaces, which have
>to be kept in sync with user code very tightly.
>  
>
Binary is fine by me.  Ascii *also* has to be kept in sync, even if its 
more readable, its just as much an interface as binary.

>And yes, we could use ascii in the event list, but then again, a
>userspace version of /sbin/hotplug that writes events to a pipe that is
>read from a daemon enables the same thing to happen :)
>  
>
still a new process is spawned per event which is what we should want to 
avoid.

>thanks,
>
>greg k-h
>
>
>
>  
>