From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miles Lane Date: Wed, 07 Feb 2001 17:37:37 +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 See comments at end of message. Oliver Neukum wrote: > > On Mittwoch, 7. Februar 2001 06:17, you wrote: > > Hi, > > > > > > 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. > > Eg.: Printer 1 added -> printcap edited > Printer 1 removed -> printcap edited > Printer 2 added -> printcap edited > > You see, changing the order of events 2 and 3 is wrong. > You'd have the wrong interfaces in printcap. > > > > > database transactions that didn't interfere with each other. The > > > > configuration of a GNU/Linux operating environment is a transactable > > > > problem, and users have no business caring which hotplug action is > > > > handled first ... so long as each one is handled correctly. > > > > > > That means that transactions that might interfer are serialised. > > > However is see no way you could tell which transactions might interfer. > > > Thus you have to serialise them all. > > > > The way you resolve this is saying that transactions in different > > subsystems may not interfere (else they're bugs) and that individual > > subsystems get to define their own rules ... but the default expectation > > should be that two devices hotplugging must NOT interfere with each other. > > At some level the function of devices enters the game. > The hotplugging events must be generated on the physical busses > to allow module autoloading, yet they come into contact by the device nodes. > > Both a disk on FC-AL in the next building and a PCMCIA SCSI controller share > the same device node space. > > The amount of locking needed to be provided by shell scripts worries me. > > > 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. > This is difficult, for several reasons. > a) You need devfs (which is not PC) > b) You know that name only after the driver is loaded. (You don't even know > the number of names, multifunction devices and bridges) > c) You'd need to call after drivers have bound to interfaces. > d) There might be devices which have difficulties providing a stable name. > > 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. Hi, I am leaving this message intact, because I think it's a good snapshot of several important issues. So, the process looks something like this: Device detection Module loads Device nodes enabled Usermode scripts (or daemon) run to do things like launch programs to upload data to a device via one of its device nodes. Now, we need to figure out a robust way to recover from devices being unplugged and new devices being inserted that reuse device nodes. Obviously, any usermode configuration scripts that fired off for the previous device will still be running and we'd then have two instances of that configuration script running and trying to access devices on the same device nodes. Not good. So, it seems that we need a way of telling all usermode scripts (or daemons) to back out any work done that depends on a given device node when we discover that the associated device has been unplugged. We then need a method of having any new usermode scripts that will be accessing the same device nodes to wait until the previous script (or daemon) has completed the back out process. Then there's the question of what to do when a user application has already been launched which will be expecting access to the first device. For example, I plug in a videocam and then unplug it, but my video viewing program has already been launched. Perhaps this isn't a huge problem. If I then connect a different videocam, it would reuse the video0 device node. Hmm. Yes, this seems like a really messy situation. Miles _______________________________________________ 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