[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1175449366.3008.120.camel@zelda.fubar.dk>
Date: Sun, 01 Apr 2007 13:42:46 -0400
From: David Zeuthen <davidz@...hat.com>
To: Pavel Machek <pavel@....cz>
Cc: Maxim <maximlevitsky@...il.com>, Pete Zaitcev <zaitcev@...hat.com>,
Alan Stern <stern@...land.harvard.edu>, gregkh@...e.de,
Kernel development list <linux-kernel@...r.kernel.org>,
USB development list <linux-usb-devel@...ts.sourceforge.net>
Subject: Re: USB: on suspend to ram/disk all usb devices are replugged
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists