Hi Mitch, > Or we can just ressurect the patch I made 2 years ago that just kills > ATM_ITF_ANY since it's a really bad idea and always was: > http://sourceforge.net/mailarchive/message.php?msg_id=6032218 > (Note: that patch also adds auto-loading of devices)
why is it a bad idea? > The real problems of having an ATM device asynchronously dissappear needs > some work to fix -- probably dead atm_dev's need to be garbage-collected > after the final VCC close happens (but have them disappear from atm_devs > immediately). It requires some thought to get the API ramifications right > but it's not impossible. Are you talking about the problem that you might try to connect to a dead device? Otherwise, I don't see that there is a problem (well, there is a problem with pppoatm, but that's different). > But don't paper over the problem by recommending people use ATM_ITF_ANY. > That's seriously the wrong thing to do. I think it's safe to assume that if a USB device is disconnected and reconnected then the old USB device will have called shutdown_atm_dev (this is called in the disconnect method) before the new USB device creates an ATM device (this is done in the probe method or later). But I'm not sure. It might not be true if someone managed to unplug from one port and plug into another in less than 200 milliseconds. It also might not be true I suppose if the device was disconnected by the hub due to some kind of electrical problem, and reassigned by the hub to a different port (I don't know if any hubs play this kind of trick). I guess that any kind of disconnect/reconnect on the same USB port, real or logical, will see the old device disconnected before the new device is probed. Maybe some of the USB guys can confirm this. In that case, we only need to be able to handle attempts to open a connection in the following situation: - there are some dead devices for which shutdown_atm_dev has been called; these devices would have accepted a connection when they were alive, but now their open methods will return a failure code - there is a live device, added after the other devices were marked as dead, which will accept the connection if asked; the connection should be made to this device Currently ATM_ITF_ANY handles this: it walks all devices, dead or alive, and tries the find one that will accept a connection. What is wrong with that? If instead ATM_ITF_ANY just tried the most recently added device, that would work too in this case, but it seems like a pointless loss of functionality. Autoloading of devices doesn't help in this case since the USB device is either plugged in (and thus exists as an ATM device), or it isn't, and no software can make it so! (Though you could generate a message asking the user to plug it in ;) ). As you can see, I'm confused by your statement that ATM_ITF_ANY is a bad idea: it seems like a fine idea to me. All the best, Duncan. ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
