From: David Zeuthen <davidz@redhat.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Maxim <maximlevitsky@gmail.com>,
Pete Zaitcev <zaitcev@redhat.com>,
Alan Stern <stern@rowland.harvard.edu>,
gregkh@suse.de,
Kernel development list <linux-kernel@vger.kernel.org>,
USB development list <linux-usb-devel@lists.sourceforge.net>
Subject: Re: USB: on suspend to ram/disk all usb devices are replugged
Date: Sun, 01 Apr 2007 13:42:46 -0400 [thread overview]
Message-ID: <1175449366.3008.120.camel@zelda.fubar.dk> (raw)
In-Reply-To: <20070401152957.GA5068@ucw.cz>
On Sun, 2007-04-01 at 15:29 +0000, Pavel Machek wrote:
> Hi!
>
> > > > In that case the user would see data corruption - just as if he mounts a piece
> > > > of removable media in a USB card reader; yanks out the card and modifies it
> > > > elsewhere, and then puts it back in.
> > >
> > > > I my opinion we can't really defend ourselves against such users... We can of
> > > > course add checks in the file system drivers in the resume hooks to validate the
> > > > super block and mount read-only if something change.
> > >
> > > The GNOME hath spoken?
>
> > I also thought about that,
> >
> > I think that the best solution is still to hide connect/disconnect of usb devices from userspace (now it also causes corruption)
> > But to refuse suspend with any usb mass storage device connected with mounted systems (and add a module param override
> > for users who know what they are doing)
> >
> > What do you think ?
>
> Agreed... and notice how easy is to do that in userspace :-))).
>
The problem with refusing to suspend with usb mass storage devices
mounted is just not going to work; the way we want desktop power
management to work is that the system automatically does s2ram or s2disk
when
- the system is idle
- the user closes the laptop lid
(all this is of course configurable but these are the defaults
in many distributions of Linux.)
and the kernel refusing to suspend in these cases may result in e.g. the
laptop melting because the lid is closed. For example, in
gnome-power-manager we play a loud "boohoo" sound if suspend fails when
closing the lid. It's all we can do really, the user have closed the lid
and if we didn't alert her _in some way_ the result would be a melted
laptop. You have to realize that people use their system in such a way.
Suspending when idle is really important too, since at some point there
will be legislation (akin to accessibility, e.g. the US's section 508)
that mandates that e.g. the US government will not buy systems that
don't conserve power by going to sleep when idle. That's an incentive at
least for "enterprise distributions" to fix this; more importantly, I
personally think that we have a moral obligation to do all that we can
to conserve power. Refusing to suspend means that many systems with USB
mass storage devices attached will consume e.g. 300W instead of 8W. I
don't know about you, but that sounds awfully wasteful to me.
And there's this: suggesting to just provide an option for people to
override this is not useful; any sane desktop distro will use that
override because users _expect_ that their laptop suspends when they
close the lid and they don't really or know care whether some drive is
connected via USB.
I hate to play this card, but you may want to look at other desktop
operating systems like Mac OS X and Windows - they don't give you USB
disconnects/reconnects on suspend and apps runs fine and can continue
accessing files on mounted USB devices upon resume.
I hope this clarifies the request. Thanks for considering.
David
next prev parent reply other threads:[~2007-04-01 17:43 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-27 16:24 Maxim Levitsky
2007-03-27 17:15 ` Alan Stern
2007-03-27 17:54 ` Maxim
2007-03-27 18:05 ` Pete Zaitcev
2007-03-27 23:29 ` Maxim
2007-04-01 15:29 ` Pavel Machek
2007-04-01 17:42 ` David Zeuthen [this message]
2007-04-01 17:50 ` Pavel Machek
2007-04-01 18:01 ` David Zeuthen
2007-04-01 18:29 ` Pavel Machek
2007-04-01 18:26 ` Alan Stern
2007-04-01 18:34 ` Pavel Machek
2007-04-01 20:53 ` Rafael J. Wysocki
2007-04-02 2:54 ` Alan Stern
2007-04-02 20:37 ` Rafael J. Wysocki
2007-04-02 18:38 ` Chuck Ebbert
2007-04-02 19:36 ` Pavel Machek
2007-04-06 22:23 ` Nigel Cunningham
2007-04-02 14:49 ` Mark Lord
2007-04-02 18:28 ` Pavel Machek
2007-03-29 13:19 ` Mark Lord
2007-03-29 15:56 ` Alan Stern
2007-03-29 16:03 ` Mark Lord
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1175449366.3008.120.camel@zelda.fubar.dk \
--to=davidz@redhat.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=maximlevitsky@gmail.com \
--cc=pavel@ucw.cz \
--cc=stern@rowland.harvard.edu \
--cc=zaitcev@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®