From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Tue, 06 Feb 2001 19:31:39 +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 > From: "David Woodhouse" > Sent: Monday, February 05, 2001 11:11 PM > > 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. Originally they _were_ serialized, because the usermode helpers were called synchronously by threads that only reported the events in the appropriate sequence. That is, serialization between subsystems wasn't provided (shouldn't be, IMO), only within the subsystem (say USB or PCI, which provided the thread). My short version of "why did that change" was that the addition of network hotplugging turned up some races (the network driver API wasn't designed for hotplugging, unlike USB or PCI, and some locks were held so usermode "ifconfig" could deadlock) and changing all that was the expedient way out. Andrew Morton can elaborate; from test5 through test11, hotplugging was synchronous, without any reported problems when used with USB. > 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). By itself, a queue won't solve the problems. Entry #1: new device /proc/bus/usb/001/004 ... Entry #N: removes it ... Entry #M, new device reusing the /proc/bus/usb/001/004 name. Synchronization of some kind is needed. ("devfsd" dealt with some of these issues, not that I use it; there may be ideas woth stealing from it.) This subproblem might get simpler if the hotplug notifications can't do more than identify a device type, and they can't access devices (for stuff like serial numbers, alternative configurations, and other such "extended type info") ... but that surely rules out some kinds of necessary response to hotplug notifications. > > 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. Modulo races between usermode code accessing devices using those names, and the kernel invalidating and reusing them, yes. "usbdevfs" lets those issues be solved by keeping device nodes in that namespace until the last open FD is gone, but there's a role for non-kernel code to play too (talk to the FS safely, which can't quite be done with the hotplug agent getting called asynchronously). Not to overstate things: typical usage scenarios today (only a few devices, usage patterns still evolving) probably won't suffer too much from these problems. Yet. - Dave _______________________________________________ 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