Duncan Sands wrote: > > 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?
Because it makes no sense semantically. Imagine if you have two ATM cards in your computer. Under what circumstances would it make sense to say "give me VPI.VCI 0.50, but I don't care what card it goes out"? It really isn't meaningful -- VPI.VCI's are not like IP addresses; they are only meaningful in the context of the link they're on. Thats why my patch changes ATM_ITF_ANY to just mean "the first interface on the list" That way ATM_ITF_ANY doesn't change behavior for the common case where you have a single device. Now what you're trying to use it for is to say "well, we only have ONE device but its showing up in the list twice because there's a zombie entry. So I want to ignore the failure of that open()" But thats just papering over the real problem -- that the dead device is appearing _at_all_. We really need to add a new API allowing a device to asynchronously deregister itself and immediately give up its device # but allow the atm_dev structure to live until the last atm_vcc closes. Then the modem can keep it's correct interface number and this problem just goes away. The core ATM API has changed fairly little in over 10 years -- when it was designed the idea of a hot-pluggable ATM card was pretty far-fetched :-) > 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 ;) ). Yes, its just in the same patch. I came up with a bunch of patches around that time to try to make ATM modules auto-load better (although they didn't generate much interest and never really went anywhere) -- the ATM_ITF_ANY change was just a side-effect of one of them. -Mitch ------------------------------------------------------- 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