linux-kernel - Re: Attempted summary of suspend-blockers LKML thread, take three

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100814104130.GA29894@elf.ucw.cz>
Date:	Sat, 14 Aug 2010 12:41:30 +0200
From:	Pavel Machek <pavel@....cz>
To:	Arve Hj?nnev?g <arve@...roid.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Brian Swetland <swetland@...gle.com>,
	Felipe Contreras <felipe.contreras@...il.com>,
	Ted Ts'o <tytso@....edu>,
	Alan Stern <stern@...land.harvard.edu>,
	paulmck@...ux.vnet.ibm.com, Alan Cox <alan@...rguk.ukuu.org.uk>,
	david@...g.hm, linux-pm@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, mjg59@...f.ucam.org,
	florian@...kler.org, peterz@...radead.org, tglx@...utronix.de,
	menage@...gle.com, david-b@...bell.net, James.Bottomley@...e.de,
	arjan@...radead.org, swmike@....pp.se, galibert@...ox.com,
	dipankar@...ibm.com
Subject: Re: Attempted summary of suspend-blockers LKML thread, take three

Hi!

> >  Arguably, though, this isn't the only possible way to implement a
> > mechanism allowing the system to be suspended automatically when it appears
> > to be inactive.
> >
> > Namely, one can use a user space power manager for this purpose and actually
> > the OLPC project has been doing that successfully for some time, which clearly
> > demonstrates that the Android approach to this problem is not the only one
> > possible.  Moreover, the kernel's system suspend (or hibernate for that matter)
> > code has not been designed to be started from within the kernel.  It's been
> > designed to allow a privileged user space process to request the kernel to
> > put the system into a sleep state at any given time regardless of what the
> > other user space processes are doing.  While it can be started from within the
> > kernel, this isn't particularly nice and, in the Android case, starting it from
> > within the kernel requires permission from multiple user space processes
> > (given by not taking suspend blockers these processes are allowed to use).
> >
> 
> Why is starting suspend from within the kernel not nice? Personally I
> think reentering suspend from within the kernel is nicer than being
> forced to wake up a user space thread for events that are fully
> handled within the kernel (for instance the battery monitor on the
> Nexus One).

For events that are fully handled within the kernel -- like battery
monitor on Zaurus/spitz -- doing wakeup all the way to the userspace
is not neccessary. But that's implementenation detail with no impact
on user/kernel interface, and we are doing that today. (Or were doing
that few releases ago; charging is broken on spitz just now).
									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/