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

From: Phillip Susi
Date: Mon Feb 20 2006 - 11:06:57 EST


David Brownell wrote:

Exactly: ignore those disconnects in "some" cases. Suspend-to-RAM
will typically never report disconnects without a real unplug. You
want to add special casing for hibernate/swsusp. (A point in favor
of someone's claim that hibernate/swsusp is structurally harder.)


Typical != always. It may be more common for suspend to maintain usb power, but both suspend and hibernate may or may not maintain usb power, so the kernel needs to be prepared to deal with that in both cases.


Now with /dev/input/mice, the driver stack above USB is able to mask
such disconnects. It's not like mice maintain state that matters.
The "ignore" is in stack layers way above USB, which can know a very
important thing about mice: they are stateless.

But with storage media, there is no such mechanism ... and there's
significant state involved. Adding a "reconnect" mechanism, and
getting it wrong for storage, likely means corrupted file systems.
And where even if it _is_ the same physical disk, there's no good
reason to expect it hasn't been modified on some other usb host.
(Toss hardware in bag, reuse as needed...)


And this is exactly how non USB hardware has behaved for eons, and it hasn't been a problem. If you want to add some verification to make reasonably sure that the media has not been modified, that is great, but you can't just automatically dump the filesystem and kill running processes and loose data just because something bad _may_ have happened.

No thanks, I prefer data integrity. And for that matter, re $SUBJECT,
the much simpler approach of working _with_ the hardware architecture,
not against it.


Again, the hardware is perfectly free to power off the usb bus during suspend to ram. Most systems choose not to because they allow wake from usb, but not all do.


But yes, you're right ... if he's serious about
changing all that stuff, he also needs stop being a
member of the "never submitted a USB patch" club.
Ideally, starting with small things.
You're moving off into left field.

Not hardly. Unless all you're doing here is flaming?
One point of $SUBJECT was that flames were _over_ ...


Left field is where flames are, which is what the comment was that I was replying to -- a flame.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/