Hi Mitch, On Thursday 17 November 2005 14:59, Mitchell Blank Jr wrote: > 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.
ok, you certainly have a point. On a slightly different topic, if you have more than one modem, don't they end up being assigned interface numbers in a random order - how to deal with that? > 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. But what does this change buy you? Maybe the current setup is rather meaningless, but how is choosing device 0 any less meaningless? In the common case of a single device, the behaviour would be the same. Or is the point that you can simplify the code a lot? > 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_. It's clearly the case that attempts to connect to a dead device should be rejected. It's less clear to me that recycling interface numbers faster is the real solution - isn't that just papering over the problem that interface numbers are meaningless, and get handed out rather randomly? It would be better if devices could be specified by some sort of universally meaningful thing, like the MAC address (do ATM cards have these - the speedtouch modems do, and store it in esi). > 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. Why is it the "correct interface number"? If I have two USB modems (say interfaces 0 and 1) and I restart the hotplug subsystem, they will both be disconnected and reconnected. Even with such an API as you suggest, there is nothing to stop them being assigned interface numbers 1 and 0 on reconnection. Is that wrong? > 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. Best wishes, 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
