Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Miles Lane <miles@megapathdsl.net>]

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