>>>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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/