Oliver Neukum wrote:
You misunderstand what it's supposed to do. The idea is to put the interface into the same state it's in before any driver binds to it. There's no reason for that to be anything other than atomic: race-free.Putting it into that state is no problem, but keeping it in that state is.
In short, you're saying that request does exactly what it's intended to do. Being unbound has always been a temporary state, I don't see any particular benefit to making it sticky. Do any other Linux driver frameworks work that way?
If there's a race binding to some other driver (one more appropriate to the application), that race would be present in _all_ binding paths ... there should be nothing unique to doing it through usbfs.That exactly is the problem. That 'state' is not a stable state. If you want to have an unbound device you need to protect that device from bindinding. Simple unbinding is a useless concept.
It's actually a "mostly stable" case. Think about the handful of opportunities drivers have to bind. After that request, the interface will stay unbound unless someone modprobes a driver that happens to handle it, or binds to it using usbfs.
The end goal isn't to keep the interface un-bound ... it'sCould you explain yourself more clearly?
to get the _right_ driver bound, user mode or kernel mode.
The potential trouble is if the right driver is user mode,
and someone modprobes a wrong driver between two requests
made through usbfs. That's not only a really small window
for something that's already unlikely, but the workaround
is a simple retry.
- Dave
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
