Linux Power Management development
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Pavel Machek <pavel@ucw.cz>
Cc: Linux PM list <linux-pm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration
Date: Sat, 14 Jun 2014 01:19:18 +0200	[thread overview]
Message-ID: <2242480.eT2OxdNqLH@vostro.rjw.lan> (raw)
In-Reply-To: <34237308.7Kff3QYgup@vostro.rjw.lan>

On Saturday, June 14, 2014 12:23:15 AM Rafael J. Wysocki wrote:
> On Saturday, June 14, 2014 12:16:26 AM Rafael J. Wysocki wrote:
> > On Friday, June 13, 2014 11:46:12 PM Pavel Machek wrote:
> 
> [...]
> 
> > > > So I'm really not sure what's the problem?  Do you think it's wrong to be
> > > > helpful to users or something?
> > > 
> > > It is not wrong to be helpful, but messed up interface is too big a
> > > price.
> > 
> > Why?  I will have to maintain it after all, right?
> 
> And by the way, the very fact that this workaround is even useful in some cases
> indicates that the interface that we've invented originally is not particularly
> useful to user space.  The reason why is because user space is supposed to
> enumerate the sleep states and then present the ones that are present in a
> consistent way to the user.  It basically has to do "Is 'mem' present"?  Use it
> if so, but if not is 'standby' present?  Use it if so etc." every time or
> squirrel that information somewhere which isn't particularly straightforward.

Moreover, the "mem" and "standby" states are not really well defined on anything
different from ACPI, so "mem" is used by everybody having just one platform-supported
state.  That's why user space doesn't bother to check the other ones in many
cases and it is not really their problem.  It is the problem of our existing
interface that wasn't designed correctly.

My first reaction to this issue was pretty much the same as yours, but when I started
to think more about it, I've realized that we messed up things to start with and now
we're just having to deal with the consequences.  So yes, we can put our heads in
the ground and say "that's not our problem, it has to be addressed in user space",
but quite frankly I'm not seeing how we can persuade user space developers address
it given that the vast majority of systems use "mem" only anyway and that they don't
really understand where the problem is.

For this reason I'm considering changing the defaul behavior going forward (so
that "mem" is always present and means "the deepest sleep state available other
than hibernation"), but I don't want to do that in one go.

Rafael


  reply	other threads:[~2014-06-13 23:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-22 23:21 [PATCH 0/3] PM / sleep: Make it possible to change the labeling of sleep states Rafael J. Wysocki
2014-05-22 23:22 ` [PATCH 1/3] PM / sleep: Add state field to pm_states[] entries Rafael J. Wysocki
2014-05-22 23:23 ` [PATCH 2/3] PM / sleep: Use valid_state() for platform-dependent sleep states only Rafael J. Wysocki
2014-05-23 13:01   ` [PATCH 2/3][update] " Rafael J. Wysocki
2014-05-22 23:24 ` [PATCH 3/3] PM / sleep: Introduce command line argument for sleep states enumeration Rafael J. Wysocki
2014-05-23 13:03   ` [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration Rafael J. Wysocki
2014-05-26  8:31     ` Srivatsa S. Bhat
2014-05-26 11:00       ` Rafael J. Wysocki
2014-05-26 10:55         ` Srivatsa S. Bhat
2014-06-10 13:12     ` Pavel Machek
2014-06-10 15:23       ` Rafael J. Wysocki
2014-06-10 15:25         ` Rafael J. Wysocki
2014-06-10 19:59         ` Pavel Machek
2014-06-10 20:34           ` Rafael J. Wysocki
2014-06-13 21:46             ` Pavel Machek
2014-06-13 22:16               ` Rafael J. Wysocki
2014-06-13 22:23                 ` Rafael J. Wysocki
2014-06-13 23:19                   ` Rafael J. Wysocki [this message]
2014-07-30 10:55                     ` Pavel Machek
2014-08-01 13:54                       ` Rafael J. Wysocki
2014-08-16  8:10                         ` Pavel Machek
2014-08-17  4:16                           ` Rafael J. Wysocki

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=2242480.eT2OxdNqLH@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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