lkml.org 
[lkml]   [2006]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Flames over -- Re: Which is simpler?
Date
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/

\
 
 \ /
  Last update: 2006-02-14 05:11    [W:0.132 / U:0.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site