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

[Oliver Neukum <Oliver.Neukum@lrz.uni-muenchen.de>]

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.

	Regards
		Oliver

_______________________________________________
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