lkml.org 
[lkml]   [2009]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Run-time PM idea (was: Re: [linux-pm] [RFC][PATCH 0/2] PM: Rearrange core suspend code)
On Mon, Jun 08, 2009 at 03:46:47PM +0200, Ingo Molnar wrote:
>
> * Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > How does the kernel know whether the user cares about SATA hotplug
> > or not?
>
> The typical user probably doesnt know what 'SATA' means, and
> probably has very vague concepts about 'hotplug' as well.

eSATA is pretty common now.

> The kernel default should be: 'yes, if the kernel feature is enabled
> and if the hardware can support it' (it's not on a blacklist of some
> sort, etc., etc.).

The problem with this kind of default is that you get people who are
confused that their hardware doesn't work. If the kernel doesn't have
enough information to make a decision it should err on the side of
functionality - we're talking about fairly low-level power savings, but
potentially several years of aggregate confusion on the part of users.

> > It'll be up to the distributions to provide sane defaults and let
> > them be reconfigured as necessary, depending on the information we
> > have from the user and maybe platform-specific knowledge. But this
> > is a difficult problem - we need to be smart about all the
> > potential sources of information in order to pick an appropriate
> > policy, and the kernel's not the right layer to do some of this
> > information collection.
>
> What sources of information exactly? Again, the user wont enter
> anything, in 95% of the cases - in the remaining 3% of cases what is
> entered is wrong and only in another 2% of cases is it correct ;-)

Users are generally ok at realising correlation between a setting change
and something no longer working, so as long as you provide that they'll
be happy. I agree that this sucks. What we actually want is some means
of reliably identifying whether a port is hotplug or not, but eSATA
makes this very difficult.

> Sure, there might be tradeoffs when a piece of hardware cannot be
> turned off sanely: obviously the monitor might not know it
> (currently) whether someone is watching it, and
> wake-on-packet-for-me is not commonly implemented in wireless and
> wired networking cards so turning off an active networking card
> might not be possible without the user asking allowing that
> imperfect mode of power saving.

These cases can all be handled with sufficiently intelligent userland,
so I'm not worried about them.

> ( Providing a way to _override_ those defaults is of course natural,
> via /sysfs, should the user express an interest in tweaking it, or
> should the kernel get it so wrong that a distro wants to work it
> around. But your argument seems to be "push configuration and
> handling into user-space" which is really backwards. )

My argument is "Hardware should work, and if the kernel default is for
it to be broken then the default is wrong". We went through this for USB
autosuspend. Userspace simply has more available information than the
kernel, and it's not just a matter of static configuration (though that
may be part of it). For instance, Oliver's example of screensavers and
USB keyboards. If nothing's paying attention to volume keys (or if the
keyboard doesn't have any) then you can enable remote wakeup and suspend
the keyboard. If something /is/ paying attention to volume keys, you
can't do that. That's the kind of case I'm discussing.

--
Matthew Garrett | mjg59@srcf.ucam.org


\
 
 \ /
  Last update: 2009-06-08 15:57    [W:0.091 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site