From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Adam J. Richter" Date: Thu, 08 Feb 2001 09:29:27 +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 >> 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