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

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

> >You need to prevent any changes to the bus while you do the scanning.
> >Running hotplug support is not enough. You need further kernel support
> >to do racefree scanning.
>
> 	You cannot lock physical reality.

To a certain extent you can. You cannot hide removal, but you can hide 
addition. That's enough.

> 	In any case, the doubt that I originally expressed was about
> the need to queue hotplug events _before_ the hot plug system was
> initialized.  In your example, the events occur after the hot plug
> system is initialized.

No, it occurs while you are initialising the hotplug system.
You cannot scan a bus without locking it.
While you lock the bus what do you do with the events ?

You could indeed do without queueing initial events, if you did
scan the bus under lock.
Provided that you give stable names (David's definition) to the agents
in order to be able to loose information about ordering of events.

> 	However, now that you mention it, let's talk about handling
> events that occur after initialization.  I think we can avoid the
> need to queue those events too.
>
> 	First of all, we should recognize that for most hardware,
> the events caused by unplugging are handled directly by the kernel,
> not by the user level hot plugging code.  For example, with a DHCP
> configured ethernet, removal of the ethernet interface card should
> cause the socket that dhcp has open on the ethernet interface to
> return an IO exception condition, and dhclient should get -EIO
> and abort when it tries to execute the ioctl to check the status.

I am afraid I have to disagree. Most hardware is associated with device nodes
in /dev which retain their permission bits. You have to reset them on removal.

> 	Secondly, there is a way to get this processing right
> where necessary without the need to queue events (which can overflow,
> and involve maintiaining arbitrary large dynamic data strucutres).
> All you need is a "new" flag that the kernel would set when on a device
> when it is inserted.  The hot plug code would be called by the kernel
> with an argument indicating what device to check, without necessarily
> even indicating whether it was a hot plug or a remove event.
>
> 	userland_hotplug_handler(dev)
> 	{
> 		// was_plugged_in[dev] is persistent data, perhaps
> 		// stored in a file.
>
> 		acquire_lock(dev);   // Flock some file; could just have
> 				     // one global lock.  Whatever.
> 		if (was_plugged_in[dev]
> 		    && (new[dev] || !is_plugged_in[dev])) {
				^ race condition, the condition you check for might change
> 			was_plugged_in[dev] = 0;
> 			handle_remove_event(dev);
> 		}

and you may forget a removal event this way, which is bad

> 		if (new[dev]) {
> 			new[dev] = 0;
> 			if (is_plugged_in[dev]) {
> 				was_plugged_in[dev] = 1;
> 				handle_insert_event(device);
> 			}
> 		}
> 		old_status[dev] = new_status;
> 		release_lock(dev);
> 	}

The problem is is_plugged_in[]. It has to come from the kernel in last 
consequence. To avoid the race condition in the code above, acquire_lock has 
to lock is_plugged_in[], too. That means it has a need for kernel support.
Then what is the kernel supposed to do about events arriving while the lock 
is held ? Dropping them causes a race which can lead to events being lost.
You have to queue them (or at least set a flag, if you use stable names). 

	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