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:4.163 / U:0.224 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site