[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87k4r24avj.fsf@deeprootsystems.com>
Date: Mon, 17 May 2010 11:54:40 -0700
From: Kevin Hilman <khilman@...prootsystems.com>
To: James Bottomley <James.Bottomley@...e.de>
Cc: me@...ipebalbi.com, Alan Stern <stern@...land.harvard.edu>,
linux-omap@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
Geoff Smith <geoffx.smith@...el.com>,
Brian Swetland <swetland@...gle.com>,
Kernel development list <linux-kernel@...r.kernel.org>,
Oleg Nesterov <oleg@...hat.com>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>,
Tejun Heo <tj@...nel.org>,
Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
Arjan van de Ven <arjan@...radead.org>,
Liam Girdwood <lrg@...mlogic.co.uk>,
Matthew Garrett <mjg@...hat.com>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
James Bottomley <James.Bottomley@...e.de> writes:
> The technical reason for wanting suspend blockers (as has been stated
> more times than I can be bothered to go back and count) is that no-one
> can currently produce a working model for race free kernel to user work
> handoff
At least I've never heard this technial reason stated so succinctly. It's
not in the changelogs or in the Documentation file included.
The way I undertand things, today's mainline kernel has a race-free
kernel-to-user work handoff already.
The possibility of races is introduced by the opportunistic suspend
feature itself (patch 1.) The use of suspend blockers later in the
series is needed to avoid the potential races introduced by
opportunistic suspend.
Kevin
--
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