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

[David Brownell <david-b@pacbell.net>]

On Saturday 18 February 2006 10:06 pm, Phillip Susi wrote:
> David Brownell wrote:
> > 
> > Hardware is CORRECTLY reporting electrical disconnects,
> > but Philip is wanting Linux to ignore those reports.
> 
> No, not ignore, just realize that an electrical disconnection does not 
> necessarily mean that the volume can no longer be accessed.

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


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

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.


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

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