I'm talking about protecting the physical topology of the entire tree.
I still don't see why the _entire_ tree needs that sort of protection. I hope I'm not missing something.
And I would find it acceptable to use hubdev->serialize to protect the links at the inner nodes if only I could see how to also get usb_reset_device() working reliably. And useable from within probe().
I think usb_reset_device(dev) would just need to call locktree(dev), then fail cleanly on -ENODEV returns.
As for usable from probe() ... I just had the germ of an idea. How about splitting out the "logical" topology lock (protecting SET_CONFIGURATION, while it's probing every interface) from the "physical" topology lock (hub->serialize)? A single bit in "struct usb_device" would suffice to prevent nested calls to the usb_set_configuration() routine, during probe(), which would cause self-deadlock (and other chaos).
In fact, the only problem I _have_ been able to identify is: "What happens when khubd is multi-threaded and different threads try to disconnect overlapping subtrees simultaneously?" (Obviously it's not an issue at the
Erm, if subtrees are overlapping, then one of them is a strict superset of the other and you really only have one subtree being disconnected.
Yes, but you still might have two processes working on overlapping subtrees at the same time. For instance, khubd gets a port-connect-change on some port, and while it's working on that you rmmod the HCD. With top-down locking this probably isn't too bad a problem.
N tasks can work concurrently if they agree on a common, and correct!, locking protocol. I know there's a correct top-down protocol lurking, given hiearchical hardware (like USB). I'm pretty sure we've hit on the key points of such a protocol ... but theories need testing!
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
