lkml.org 
[lkml]   [2006]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Flames over -- Re: Which is simpler?
Kyle Moffett wrote:
>
> No, that information is the most reliable that can be obtained. It
> tells us that we can no longer make any guarantees about the device or
> its state. The USB spec is quite clear on this point.
>

That is what it says but the kernel is interpreting it as "this device
HAS been removed" rather than "this device MAY have been removed". That
is wrong and should be fixed.

>
> Except we can't reliably decide that. Say I plug my USB camera in,
> mount it, and download some pictures. I then suspend the computer,
> unplug the camera after suspending, take more pictures, plug it back in
> and resume. That's a fairly reasonable situation and the computer
> considering the camera's state to be unchanged would be a serious bug
> and probably result in data loss. By contrast, just considering the
> camera to be spontaneously unplugged would cause no more data loss than
> actually spontaneously unplugging the flash drive.
>

But again, that would be user error and thus, the data loss can not be
avoided and is their fault. Having data loss result from user error is
far more acceptable than having data loss ALLWAYS result from a
perfectly acceptable user action, namely hibernating the machine and
resuming it some time later without altering anything. You already
teach users not to unplug the drive without ejecting it from the desktop
first, why should you also force them to eject before hibernating?

>
> This is why hardware suspend is a good thing. When I suspend and resume
> my laptop, there are _no_ USB disconnects. The controller puts all the
> hubs into low-power mode, but it never disconnects them or causes problems.
>

That's fantastic for your system, but not all systems will maintain
standby power to USB, and users expect to be able to suspend to disk and
not loose data, just like they do with non USB drives.

>
> No, you have this wrong. The USB spec indicates that the device _HAS_
> changed and all old state should be thrown away (even the address).
> There is no way around that issue. USB was designed to support hardware
> suspend; you can put all the hardware in low-power mode and still be
> able to detect changes.

That's great, except that feature is not always used so you must be able
to live without it. The fact that the hardware flag is set is no
indication that the hardware HAS changed, you said so yourself; all it
knows is that the bus/device lost power. The use case we are talking
about is one in which power loss happens, but the device is still the
same, and so access to it should not be interrupted.

>
> In fact, I would argue that turning off all the busses completely when
> you want to maintain a connection to a device is broken. If you want to
> maintain the connection, you should keep the busses powered. Otherwise,
> according to the USB spec, it's the _kernel_ that is terminating the
> connection, and assuming that it exists after explicitly terminating it
> is wrong.
>

Yes, assuming that it exists is wrong. Probing the hardware and seeing
that it exists and is _probably_ the same device is entirely different.
In that case it is preferable to assume the probable case rather than
the improbable one because it will lead to less data loss.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-02-14 03:16    [W:0.799 / U:0.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site