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

[Kyle Moffett <mrmacman_g4@mac.com>]

On Feb 13, 2006, at 21:09, Phillip Susi wrote:
> 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.

No, that's _exactly_ what the spec says (well, not verbatim but close  
enough).  When you disconnect, both the master and slave devices are  
perfectly free to assume that the connection is completely broken and  
no state is maintained.  Anything that breaks that assumption is  
against the spec and likely to break in odd scenarios.

> [multiple data-loss arguments]

Which causes worse data-loss, writing out cached pages and filesystem  
metadata to a filesystem that has changed in the mean-time (possibly  
allocating those for metadata, etc) or forcibly unmounting it as  
though the user pulled the cable?  Most filesystems are designed to  
handle the latter (it's the same as a hard-shutdown), whereas _none_  
are designed to handle the former.

A good set of suspend scripts should handle the hardware-suspend with  
no extra work because hardware supporting hardware-suspend basically  
inevitably supports USB low-power-mode, and handle software-suspend  
by either forcibly syncing and unmounting USB filesystems or by  
failing the suspend and asking the user to.  You also could patch the  
kernel to fail a powerdown software suspend if some USB device is  
mounted or otherwise unremovably in-use.

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

Except that would make Linux broken with respect to the USB spec.  It  
is fallacious to assume that a USB device that the kernel has told to  
disconnect will still have the same state when the kernel tries to  
reconnect, even _if_ you could reliably identify it (which you can't  
because there is no serial number of any sort on a lot of devices.

Cheers,
Kyle Moffett

--
I lost interest in "blade servers" when I found they didn't throw  
knives at people who weren't supposed to be in your machine room.
  -- Anthony de Boer


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