Yes, but we can't guarantee that the driver is done with the device, or the interface after disconnect() is over. And we don't want to do that either, otherwise it makes the driver's lives a big pain.
That doesn't seem quite right. Here's what I thought the (new) story was going to be:
- Most drivers rely on the implicit claim that came from probe() success, which is implicitly released when the disconnect() returns. So those drivers have a simple rule: they can't have (or use) any pointers to that interface after disconnect() returns.
And that causes a lot of gyrations in the driver to ensure it. Look at the mess of locks in something as simple as usb-skeleton.c. Ugly and a pain in the butt to debug correctly. Look how long it took us to get it right.
I don't think it's as bad as you're saying; that particular code evolved over a long time, and unfortunately shows it. But yes, using explicit reference counting simplifies things. In 2.4 there was a time when a bunch of oops-on-disconnect bugs vanished when their drivers changed to use explicit reference counting.
- After disconnect(), the driver could keep an interface reference IF (!!) it explicitly refcounting it ... which wasn't possible before this patch, though device refcounting could until recently be a proxy for it.
Well, drivers currently use usb_get_dev() to hold this reference today. And they could use usb_get_intf() instead now.
And the current story for trying to talk to the device after disconnect() wouldn't change: it's not allowed.
Um no. It should fail. It will happen, and is allowed. This works correctly today, and we can not break this.
That's where we disagree: I'm saying it FAILS today (as in 2.4). Except in the main case, so maybe we don't disagree that much.
Although when disconnect() happens because of physical device disconnect (instead of config change, or other disconnect/rebind cases), such requests can/do fail cleanly.
Yeah, I hate the "rebind" nonsense... bleah.
That's where it fails today! As Oliver noted.
And we can't change that in the 2.6 usb host framework, because of where the problem comes from. Endpoint state is associated too directly with the device ... it should be associated with interfaces (except in some cases for ep0).
So, if you really want to give an interface to another driver, we need to just unregister it and create a new one. That way it will all "just work" properly.
Yes ... but that if the first driver were still allowed to talk to the device after disconnect() returns, then it couldn't work "properly".
We need to mark the interface as "gone" so that the usb core knows this and doesn't allow any future accesses.
Request submission bypasses the interface, so that won't help.
Anything it did could easily stomp all over the second driver's work.
...
When development starts on 2.7, one possibility would be to submit urbs directly to endpoints. Endpoints are logical children of the interfaces, as well as the real targets of the urbs, so they could be cleanly disabled as part of interface disconnect() processing.
Yes, that would be nice to do.
Oh, I've rewritten the usb-skeleton driver so that it contains no locks now (with the exception of the BKL to protect on disconnect.) It's a world simpler, but I've probably forgotten something here. I've attached it below if anyone wants to look at it.
Looks much cleaner! 2.6 starts to show its true colors. :)
I'd encourage use of dev_dbg(&dev->interface->dev) and so on. Wouldn't down_read(&usb_bus_type.subsys.rwsem) in open() let you remove BKL?
- Dave
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
