On Feb 13, 2006, at 18:47:41, Phillip Susi wrote:
Alan Stern wrote:
It doesn't decide that -- the device itself does. If the device
was connected the entire time then it will respond properly. If
it was disconnected then it will reset itself, losing its
address. Hence it will not reply to further requests at the old
address. usb_get_status() simply indicates whether or not a
response was received.
I see. Then this information is unreliable and should not be
trusted ( when resuming from a suspend ), as it leads to incorrect
behavior.
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.
Note: By "disconnected", I mean that the power session was
interrupted. So even if the cable remained plugged in, if the bus
suspend power wasn't present then the device was disconnected.
Note also that it is impossible to tell whether the cable has been
unplugged -- the hardware is capable of detecting only whether or
not the power session was interrupted.
Given those caveats, yes, I agree that the routine should not
indicate the device was disconnected if in fact it wasn't.
Exactly. Yes, there is no good way to determine _for certain_ that
the user did no do something stupid, such as replace the drive with
another one just like it, or change the contents in another
machine, but that is no reason to assume that the user DID do
something like that, and break the mount, when they in fact, did
nothing of the sort.
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.
Does the kernel have any problem figuring out when a _different_
device of the same type is connected at the old address after resume?
With USB, if the entire bus is powered off then every device on it
is automatically disconnected. By definition.
Then the kernel needs to ignore those disconnect events ( provided
that the device appears to still actually be there ) because they
are false and lead to data loss.
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.
You are complaining because you don't like the way USB was
designed. That's fine, but it leaves you advocating a non-
standardized position.
No, I am complaining because the kernel interprets the notice that
the bus gives that the device _may_ have changed as a notice that
the device in fact, _has_ changed,
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.
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.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
