Re: Flames over -- Re: Which is simpler?

[Phillip Susi <psusi@cfl.rr.com>]

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/