Re: [RFC] /sbin/hotplug multiplexor

["Kevin P. Fleming" <kpfleming@cox.net>]

Oliver Neukum wrote:

>>>Now let's be conservative and assume 16KB unswappable memory
>>>per task. Now we take the famous 4000 disk case. 64MB. A lot
>>>but probably not deadly. But multiply this by 15 and the machine is
>>>absolutely dead.
>>
>>Ok, then the "Enterprise Edition" of the distros that expect to handle
>>4000 disks will have to add the following patch to their version of the
>>hotplug package.
>>
>>In the meantime, the other 99% of current Linux users will exist just
>>fine :)
> 
> 
> Well, for a little elegance you might introduce subdirectories for each type
> of hotplug event and use only them.
> 

Personally, this is one reason why I'd much rather see a daemon-based model 
where each interested daemon can "subscribe" to the messages it is interested 
in. It's very possible (and likely, i.e. udev) that the steps involved for the 
daemon to respond to the hotplug event are so lightweight that creating a 
subprocess to handle them would be very wasteful.

Also, this lends itself to multiple levels of messaging: say, for example, 
userspace partitioning. How would the proposed scheme manage to invoke the 
userspace partition reading _after_ udev has done its job? If udev itself 
generated a message into the queue after the device node had been created, the 
partitioning code could listen for that instead of the native hotplug event.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel