In message <[EMAIL PROTECTED]>,Mitchell Blank Jr writes: >I think the fact that the kernel seems to crash if you actually try to use >it speaks to how useful people have found ATM_ITF_ANY in the past. :-) >Let's just get rid of it rather than dealing with the locking mess.
your suggested fix seems like a fine idea. returning the first interface in the list will be just fine. this will fix the problem with ppp and its simple. ATM_ITF_ANY only works well for very simple situations and this is one. >Exactly. And if you have more than one device the behavior never made much >sense so my patch doesn't make it any worse. it only makes sense if both atm interface faces are on the same network and have the same b/w. otherwise, you might want to be more selective. >> It's less clear to me that recycling interface numbers faster is the real >> solution - its not clear to me how to do this one safely. the device has been removed from the system, but there are still vcc's open. if you recycle the device number before the user space procs figure this out, you could get procs attaching to the new atm device thinking its the old device. is this a good idea? anyway, during shutdown/removal you could through the vcc table and clear vcc->dev for these broken vcc's. this would let you drop the atm_dev (since vcc's are no longer tied to the atm_dev) sooner i think. of course, things that take a reference to vcc->dev would need to use atm_dev_get() and atm_dev_put() to make the structure doesnt evaporate. >confusing. If one day your (single) ethernet card got detected as "eth12" >wouldn't you find that a little odd? some operating system do this. macosx, for instance, "assigns" a consistent interface number to each mac address (storing a table for later use). cards always show up as the same interface number. i have seen some linux distros reassign network interfaces based on mac address to keep device number consistent (since order of discovery can change in large numa systems apparently). ------------------------------------------------------- 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
