lkml.org 
[lkml]   [2006]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Flames over -- Re: Which is simpler?
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@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-20 17:11    [W:0.054 / U:0.676 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site