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 [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]
