[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140613214612.GA25712@amd.pavel.ucw.cz>
Date: Fri, 13 Jun 2014 23:46:12 +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
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?
>
> That depends on which versions of Android you're talking about. The
> newest ones use the power management interfaces we have upstream.
Ok, good, so they can fix their code.
What problem are you solving? Do you have some weird hardware where
suspend to memory is impossible?
> > Android people usually patch their kernels, anyway, so why not add
> > this one, too?
>
> I'm not talking about Android kernels, but about Android user space.
I know. Android userspace usually runs on modified kernel, so you can
simply add your patch. But I don't think its suitable for mainline.
> And this is not only about Android, other distros also have user space that
> uses "mem" only, because nobody has used anything else for a long time anyway.
> For the users of those distros, if they don't want to modify user space,
> having a kernel command line like this is actually helpful.
Yes, still its wrong place to fix it...
> 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.
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