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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Pine.LNX.4.44L0.1008171056100.1656-100000@iolanthe.rowland.org>
Date:	Tue, 17 Aug 2010 11:00:17 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Brian Swetland <swetland@...gle.com>,
	Felipe Contreras <felipe.contreras@...il.com>,
	Ted Ts'o <tytso@....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>, <arve@...roid.com>,
	<mjg59@...f.ucam.org>, <pavel@....cz>, <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

On Tue, 17 Aug 2010, Rafael J. Wysocki wrote:

> > In general, we try to keep such complexity out of the
> > kernel, but not always; there are compelling cases for putting
> > complexity in the kernel to provide uniformity and flexibility (e.g.
> > application state save/restore vs. system-wide checkpoints, the former
> > preserves the "if it can be done outside the kernel, it should be",
> > while the latter provides much greater flexibility and avoids the need
> > to port applications to potentially incompatible or unportable state
> > saves/restore libraries).
> 
> I understand that and IMO it should be decided on the case-by-case basis.
> In this particular case, however, I don't think it's appropriate to use the
> interface designed with user space in mind for implementing a kernel-based
> mechanism.

Putting the "opportunistic suspend" loop into the kernel doesn't save 
as much as one might think.  The loop itself is quite simple, and the 
task switch it entails is required in any case (since suspend must be 
carried out within a process context).  Putting it in the kernel would 
save a few user/kernel context switches, not enough to matter IMO.  And 
it wouldn't offer any greater flexibility -- it might even cut down the 
flexibility.

Alan Stern

--
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/