Am Dienstag, 4. Dezember 2007 00:03:40 schrieb Alan Stern:
> On Mon, 3 Dec 2007, Oliver Neukum wrote:
> > > unbound! So I wanted to be conservative and keep the kernel's current
> > > behavior: The suspend/resume/reset happens and the user-level driver is
> > > blissfully igorant of it.
> >
> > In theory, blissfully ignoring suspend/resume must work. Anything
> > that involves a reset cannot. User space must be prepared with
> > a surprise unplug. Surprise state change asks too much.
>
> Perhaps. But there are devices for which being reset is unlikely to
> cause any problems. Do we want userspace drivers for these devices to
> start failing unnecessarily?
Which devices are these? If the tradeoff is between that and undefined
behavior in the other case, then we want them to fail.
> There is _no_ notification sent to userspace when one of these resets
> occurs -- not even a uevent that could spark a hotplug script into
> rebinding.
Well, we do return errors, don't we?
> So yes, allowing the driver to be unbound is the "correct" approach.
> But by now we've been doing it the wrong way for so long that I'm
> hesitant to change it.
Do we? I thought at least upon reset_resume we currently call disconnect.
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
