From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Woodhouse Date: Tue, 06 Feb 2001 07:11:12 +0000 Subject: Re: Adding PCMCIA support to the kernel tree -- developers needed. 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 On Mon, 5 Feb 2001, David Brownell wrote: > Serializing the order for event reports is a concern: don't report > unplugs before you report the plug-in of that device, keep the device > identifiers stable. Er... we can wait for arbitrary lengths of time in execve(). So events aren't serialised anyway, and cannot be if you report them by running a userspace helper like this. You'd have to have a queue which is read by a single userspace process (which could perhaps be spawned when the queue becomes non-empty). > The "boot time events" are all lost unless they can be inferred > from "usbdevfs" or (for PCI) "procfs". Should be entirely feasible for a PCMCIA script to determine the devices present during boot too, rather than queuing the actual events, then. > > If you wish to wait, why not wait for activation by sysctl ? > > That is, sysctl to set the kernel "hotplug" string? Would that > then invoke "/sbin/hotplug start", or would something else > need to make sure all the relevant subsystems are well enough > initialized? I assumed this meant the threads would be spawned and wait, as I suggested, but instead of waiting till the rootfs is mounted, they'd wait for an explicit trigger from userspace, whether that's setting the 'hotplug' string or a new 'hotplug_trigger' sysctl. But that means we have kernel threads collecting waiting for userspace to trigger them, and I'm not sure that's a good idea. -- dwmw2 _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel