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

Reply via email to