From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752091Ab0ACXp1 (ORCPT ); Sun, 3 Jan 2010 18:45:27 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751556Ab0ACXp0 (ORCPT ); Sun, 3 Jan 2010 18:45:26 -0500 Received: from ogre.sisk.pl ([217.79.144.158]:51068 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751038Ab0ACXpZ convert rfc822-to-8bit (ORCPT ); Sun, 3 Jan 2010 18:45:25 -0500 From: "Rafael J. Wysocki" To: =?utf-8?q?Bart=C5=82omiej_Zimo=C5=84?= Subject: Re: [suspend/resume] Re: userspace notification from module Date: Mon, 4 Jan 2010 00:45:39 +0100 User-Agent: KMail/1.12.3 (Linux/2.6.33-rc2-tst; KDE/4.3.3; x86_64; ; ) Cc: linux-kernel@vger.kernel.org, awalls@radix.net, danborkmann@googlemail.com, linux-pm@lists.linux-foundation.org, stern@rowland.harvard.edu References: <686edb2c.6263643a.4b3f4a3b.b60b3@o2.pl> <201001040030.01256.rjw@sisk.pl> <54ac764e.502c1a33.4b4129c3.9dc1b@o2.pl> In-Reply-To: <54ac764e.502c1a33.4b4129c3.9dc1b@o2.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Message-Id: <201001040045.39517.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 04 January 2010, Bartłomiej Zimoń wrote: > Dnia 4 stycznia 2010 0:30 "Rafael J. Wysocki" napisał(a): > > > On Sunday 03 January 2010, Bartłomiej Zimoń wrote: > > > Dnia 3 stycznia 2010 22:29 "Rafael J. Wysocki" napisał(a): > > ... > > > > > > It could be even UIO module but there are no pm events reachable there? > > > > > > If it is not clean, we must extend pm-utils or write something new > > > (with backends dbus, ipc, scripts, ...) > > > But You see? We still have no information from kernel about events > > > (especialy resume) or maybe i dont see this ;/ > > > > They are available to the process that tells the kernel to suspend. > > > > Namely, to tell the kernel to suspend to RAM, the process (call it a power > > manager) needs to (for example) fprintf() "mem" to /sys/power/state. As soon > > as this happens, the kernel will start to freeze processes (except for the > > power manager itself), so the power manager knows that everything should be > > ready for the suspend before it writes to /sys/power/state. It doesn't need > > the kernel to tell it when the suspend is going to start, because it _knows_ > > that in advance. > > > > Now, the fprintf() used to trigger the suspend will not return until the resume > > is complete. So, again, when the fprintf() returns, the power manager will know > > that the resume has just finished (more precisely, the kernel side of it has > > just finished). > > > > There simply is no need for any special communication between the kernel and > > the power manager. > > > > Thx Rafael - now it clear to me. > And what do You think about sending extra signals to processes? I don't see a problem with this in principle, although I don't think signals are very suitable for this particular purpose, because you need two-way communication between the power manager and the processes it's going to notify (because it has to wait for the processes to finish their preparations and to tell it that they are ready). For this purpose it's better to have a file descriptor you can block on (like a socket or a pipe) while the other side is doing it's job. Rafael