Am Samstag, 30. November 2002 22:48 schrieb David Brownell:
> 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.
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.
> 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?
Usually, if you load a driver, you suffer the consequences.
[..]
> 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.
IMHO we'd be better off with an open through usbfs
that can kick the driver off the interface.
Regards
Oliver
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
