From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Wed, 07 Feb 2001 18:24:53 +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 > > > > When I thought about this last year, my conclusion was that it SHOULD > > > > be OK to have multiple event orderings so long as all were correctly > > > > serialized with respect to essential criteria. Just as if they were > > > > > > Essentially I believe you right. But which criteria ? > > > > "add" finishes before "remove" starts; the names of > > devices are stable while those agents execute. > > Minimal. > > These are not enough. You must ensure that "remove" has finished before you > start anything that reuses the device node. I was assuming something that I suspect we should be considering as a goal (an "architectural" one?): names passed by hotplug agents must be stable. Right now, PCI meets that requirement (PCI_SLOT). USB does not, networking does not. Before 2.4.0 went "final", USB changed its address assignment so its names (busnum/devnum) were less unstable: devnum is assigned round-robin. There's a patch I put together a while back to give USB devices stable names, but it's not integrated. I'll have to think more about Vojtech's comments. I think I will likely want the kernel to guarantee some stable name (is that a place where devfs could really help?) and let all the mappings to "virtual" names (like "eth0") be managed separately. > You see, changing the order of events 2 and 3 is wrong. > You'd have the wrong interfaces in printcap. Couldn't matter if the agent were passing the right stable names though, right? > The amount of locking needed to be provided by shell scripts worries me. Compiled code (C, Java, etc) accessing kernel configuration APIs can kick in at any time it's really needed, don't worry about that one! > > That means fixing some subsystem behaviors (using stable names for > > network interfaces, as one example). Architecturally, there is no sense > > to letting two subsystems interfere with each other. > > Then you'd need to have a stable name provided to the hotplug script. Yes ... > This is difficult, for several reasons. > a) You need devfs (which is not PC) "devfsd" is not PC for me, but I'm less clear why a "/devfs" wouldn't be fine. Anyone care to start a separate thread on such topics? > b) You know that name only after the driver is loaded. (You don't even know > the number of names, multifunction devices and bridges) Device drivers can be viewed as adapters between namespaces: loading a device driver may cause entries in other namespaces. USB device "/proc/bus/usb/002/031" may be network interface "usb0". The lower level name (USB) is known before "usbnet" is loaded, but "usb0" isn't known till afterwards ... but then, USB hotplugging sees the USB name, and network hotplugging is what sees "usb0". > c) You'd need to call after drivers have bound to interfaces. USB hotplug is called after the kernel gives drivers a chance to bind to interfaces. For network devices, hotplug is called after the driver created and registered/named a new interface. > d) There might be devices which have difficulties providing a stable name. Then let them deal with it. If the busses provide stable names, then we can federate them in some namespace that can be used by layers above the busses. "pci-02:7.3" can be a PCI device, and any driver that has a hard time turning one stable name into another likely has other problems! > These are conflicting requirements. In fact you'd need _two_ scripts. One to > load the driver, a second to configure the device the driver has bound to. You mean like the difference between /etc/hotplug/*.agent (load driver FOO) and /etc/hotplug/*/FOO (configure each new device)? :-) - 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