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

["Adam J. Richter" <adam@yggdrasil.com>]

>> 	Even for the more elaborate case, where, say, a user quickly
>> inserts an ethernet card, removes it and then inserts a wireless
>> ethernet card which might need a different initialization, my scheme
>> would get it right because it does not look for existing devices until
>> it has already initialized the hot plug event handling, since the only
>> way that the first card could be detected is if the hot plugging
>> facilties were in place in time to see its later removal and the
>> insertion of the new card.

>Exactly that's the problem. What do you wish to do when the replacement has 
>happened after you have decided to do something to the interface, but before 
>you've started your action.

>Let me make a diagramm

>enable hotplugging
>start scanning bus
>decide to assign IP to eth0
>				eth0 goes away (eg leaving 802.11 zone)
>				a PCMCIA ethernet card is plugged in
>assign IP to eth0
[...]

>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.

	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.

	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.

	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])) {
			was_plugged_in[dev] = 0;
			handle_remove_event(dev);
		}
		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);
	}

	Under this scheme, if multiple events occur on a particular
device slot, they will basically end up being coallesced together,
and the first call to /sbin/hotplug for this device will update
the situation to reflect the present status of the device
(generating possibly both an remove event and then an insert event),
and the subsequent calls to /sbin/hotplug that were queued for
that device will take no action.

	This scheme is inspired by the way similar status changes are
accumulated by USB hubs, but it should be able to work for all of the
hot plugging facilities if necessary.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

_______________________________________________
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