Messages in this thread | | | Date | Mon, 14 Apr 2003 14:24:48 -0700 | From | "Kevin P. Fleming" <> | Subject | Re: [RFC] /sbin/hotplug multiplexor |
| |
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.
- 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/
| |