From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Kevin P. Fleming" Date: Mon, 14 Apr 2003 21:24:48 +0000 Subject: Re: [RFC] /sbin/hotplug multiplexor Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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