Oliver Neukum wrote:
Am Samstag, 30. November 2002 22:48 schrieb David Brownell:

In short, you're saying that request does exactly what
it's intended to do.

Upon further thought, it doesn't. You see, simulating
a disconnect will not ensure that the device is in a usable
state. In fact, in a disconnect handler trying to quieten
a device would be wrong, but strictly speaking it's needed
here.
There's no "simulating" involved:  the driver is really
getting disconnected from the device.  Drivers that don't
stop using the device at that point ("quiescing") are
seriously (oopsably) buggy -- always have been.  You're
wrong here.


The end goal isn't to keep the interface un-bound ... it's
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.

IMO there's no such thing as a small window. Either it's a
race or it's not.
And in either case, retry to solve that potential issue.
It's not a "race" in the sense of bad things happening
to correctly written code (i.e. "bug").





-------------------------------------------------------
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

Reply via email to