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

[Kyle Moffett <mrmacman_g4@mac.com>]

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 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/