linux-kernel - Re: [suspend/resume] Re: userspace notification from module

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] [day] [month] [year] [list]

Message-ID: <20100104143823.1464643d@strolchi.home.s3e.de>
Date:	Mon, 4 Jan 2010 14:38:23 +0100
From:	Stefan Seyfried <stefan.seyfried@...glemail.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Bartłomiej Zimoń <uzi18@...pl>,
	linux-kernel@...r.kernel.org, Andy Walls <awalls@...ix.net>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: [suspend/resume] Re: userspace notification from module

Hi,

On Sun, 3 Jan 2010 22:49:11 +0100
"Rafael J. Wysocki" <rjw@...k.pl> wrote:

> On Sunday 03 January 2010, Bartłomiej Zimoń wrote:
> > mhm, why not to create kernel based pm event messaging for processes?

I don't think you need the kernel for that.

> > How it is implemented on other platforms?
> > Because on MacOsX looks like program registers callback for such event.
> > 
> > I dont know if every pm_notifier blocks suspend until return from callback.
> > 
> > If we cant do it simple we can do it better.
> > Rafael what do You think about it?

Basically, modern desktops do it exactly this way. They have one "power
manager" (be it gnome-power-manager or KDE's solid) and the
applications are notified by it if a suspend is going to happen.

E.g. the power manager will tell the volume manager (the thing that
mounted the USB stick) "we will suspend, please unmount everything".
Other desktop components will also be notified.

Some processes might also wish to inhibit the suspend (e.g. a CD
burning application while it is burning).

The power manager is the "single point of decision". It might decide to
ignore the CD burning application, if the power is critically low
(better a ruined CD than data loss by hard poweroff), but honor it
otherwise. It might decide to ask the user (and it has an easy way to
do so, since it is running in the users session and thus has access to
the X display), but proceed after a timeout etc...

All this is already possible and does not need any kernel changes at
all.

> I've just said, roughly, in a message I sent to you a while back.
> 
> You need a power manager, but not necessarily in the kernel.  The role of the
> power manager would be to:
> (1) pass suspend requests from different sources in the user space (a GUI for
>     one example) to the kernel,
> (2) notify processes which registered for that when it's going to pass a
>     suspend (or hibernate) request to the kernel,
> (3) wait for the notified processes to complete the pre-suspend preparations
>     they require.

Exactly.

> There are a few more things to consider here.  For example, what if one of the
> registered processes becomes unresponsive?  Are we going to suspend anyway
> or notify the user and wait for him to resolve the problem?  In the latter
> case, what to do if that is, for example, an emergency hibernation started
> because we're running out of battery power?  Etc.
> 
> Some time ago openSUSE had a daemon called powersaved used for this purpose,
> but then it was replaced by pm-utils, apparently because everybody else was
> using pm-utils and it just wasn't worth maintaining a different solution for
> one distro only.  Maybe it's time to rethink this idea?

No. Because what powersaved did was not fundamentally different from
what gnome-power-manager / pm-utils does now. The difference was, that
it was a daemon running as root. Which brought a few problems of its
own:
 * communication with the user was not easily possible
 * it mixed up policy and mechanism (powersaved decided what to do if
   you press the power or sleep button, and you needed root to configure
   that behaviour).

And before somebody comes along with arguments like "but what about my
manually mounted NFS share - who will unmount that?", I can only tell
you: "go away". There is no way to imlement a sane solution that will
take care of all the crazy manual configurations people can dream of,
so you can only tell them "you mounted it manually - so unmount it
manually".

And you can give them pm-utils hooks that give them a mechanism to do
their manual stuff semi-automatically during suspend / resume.

Have fun :-)

	seife
-- 
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out."
--
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/