lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ