[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140610195905.GA6805@amd.pavel.ucw.cz>
Date: Tue, 10 Jun 2014 21:59:05 +0200
From: Pavel Machek <pavel@....cz>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Linux PM list <linux-pm@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3][update] PM / sleep: Introduce command line
argument for sleep state enumeration
On Tue 2014-06-10 17:23:24, Rafael J. Wysocki wrote:
> On Tuesday, June 10, 2014 03:12:06 PM Pavel Machek wrote:
> > Hi!
> >
> > > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > >
> > > On some systems the platform doesn't support neither
> > > PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the
> > > only available system sleep state. However, some user space frameworks
> > > only use the "mem" and (sometimes) "standby" sleep state labels, so
> > > the users of those systems need to modify user space in order to be
> > > able to use system suspend at all and that is not always possible.
> >
> > I'd say we should fix the frameworks, not add option to change kernel
> > interfaces.
> >
> > Because, as you mentioned, if we add this, we are probably going to
> > get stuck with it forever :-(.
>
> Unfortunately, fixing the frameworks is rather less than realistic in any
> reasonable time frame, since Android. :-)
Actually, you still have the sources from android, and this issue
sounds almost simple enough for binary patch.
Android misuses /proc/sys/vm/drop_caches, too, IIRC. Are we going to
change interface to match their expectations? They have binder and
wakelocks. Are we going to apply those patches just because Android
wants that?
Android people usually patch their kernels, anyway, so why not add
this one, too?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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