Hotplug events for system suspend/resume

Hotplug events for system suspend/resume

[Todd Poynor]

Generate synchronous hotplug events for system suspend and resume
events, via the power subsystem.  Recent discussions have indicated
various methods for notification of these events are in use today; this
is an attempt to move these into the generic power subsystem.  The patch
relies on the "synchronous hotplug events via kobject" patch sent
previously.

I fumbled around with the best to way to hook this into kobject.
Subsystems apparently aren't setup to generate hotplug events directly,
only kobjects below a subsystem may issue hotplug events.  A notifier
kobject has been created within the power subsystem for this purpose.
Any advice welcome.

Thanks -- Todd

--- linux-2.6.6-orig/kernel/power/main.c	2004-05-10 11:26:35.000000000 -0700
+++ linux-2.6.6-pm/kernel/power/main.c	2004-05-10 17:25:30.000000000 -0700
@@ -25,6 +25,9 @@
 
 struct pm_ops * pm_ops = NULL;
 u32 pm_disk_mode = PM_DISK_SHUTDOWN;
+int pm_state = PM_SUSPEND_ON;
+
+static void power_notify(void);
 
 /**
  *	pm_set_ops - Set the global power method table. 
@@ -150,20 +153,26 @@
 		goto Unlock;
 	}
 
+	pm_state = state;
+	power_notify();
+
 	if (state == PM_SUSPEND_DISK) {
 		error = pm_suspend_disk();
-		goto Unlock;
+		goto NotifyUnlock;
 	}
 
 	pr_debug("PM: Preparing system for suspend\n");
 	if ((error = suspend_prepare(state)))
-		goto Unlock;
+		goto NotifyUnlock;
 
 	pr_debug("PM: Entering state.\n");
 	error = suspend_enter(state);
 
 	pr_debug("PM: Finishing up.\n");
 	suspend_finish(state);
+ NotifyUnlock:
+	pm_state = PM_SUSPEND_ON;
+	power_notify();
  Unlock:
 	up(&pm_sem);
 	return error;
@@ -186,8 +195,28 @@
 }
 
 
+static int power_hotplug(struct kset *kset, struct kobject *kobj, char **envp,
+			 int num_envp, char *buffer, int buffer_size)
+{
+	int i = 0;
+	int length = 0;
 
-decl_subsys(power,NULL,NULL);
+	envp[i++] = buffer;
+	length += scnprintf (buffer, buffer_size - length, "STATE=%s",
+			     pm_states[pm_state] ? pm_states[pm_state] : "on");
+	if ((buffer_size - length <= 0) || (i >= num_envp))
+		return -ENOMEM;
+	++length;
+
+	envp[i] = 0;
+	return 0;
+}
+
+static struct kset_hotplug_ops power_hotplug_ops = {
+	.hotplug =	power_hotplug,
+};
+
+decl_subsys(power,NULL,&power_hotplug_ops);
 
 
 /**
@@ -247,12 +276,28 @@
 	.attrs = g,
 };
 
+struct power_notifier {
+	struct kobject kobj;
+};
+
+static struct power_notifier power_notifier;
+
+static void power_notify()
+{
+	kobject_hotplug_wait("state-change", &power_notifier.kobj);
+}
 
 static int __init pm_init(void)
 {
 	int error = subsystem_register(&power_subsys);
 	if (!error)
 		error = sysfs_create_group(&power_subsys.kset.kobj,&attr_group);
+	if (!error) {
+		kobj_set_kset_s(&power_notifier, power_subsys);
+		error = kobject_set_name(&power_notifier.kobj, "notifier");
+		if (! error)
+			kobject_register(&power_notifier.kobj);
+	}
 	return error;
 }

Re: Hotplug events for system suspend/resume

[Greg KH]

On Mon, May 10, 2004 at 06:00:15PM -0700, Todd Poynor wrote:
> Generate synchronous hotplug events for system suspend and resume
> events, via the power subsystem.  Recent discussions have indicated
> various methods for notification of these events are in use today; this
> is an attempt to move these into the generic power subsystem.  The patch
> relies on the "synchronous hotplug events via kobject" patch sent
> previously.

I still do not see the need for this.  As a user, you caused the
suspend/resume event to happen, why get notified of it again?  :)

Or am I missing something basic here?

thanks,

greg k-h

Re: Hotplug events for system suspend/resume

[Todd Poynor]

Greg KH wrote:

> I still do not see the need for this.  As a user, you caused the
> suspend/resume event to happen, why get notified of it again?  :)

The idea is to notify the "power management application" of impending 
suspend and just-completed resume, regardless of who or what asked for 
the suspend.  Actions taken at suspend might include dropping network 
connections and saving application state to stable storage.

The reasons for which this was requested of me as a kernel-to-userspace 
notifier, that I am aware of, are:

(a) some embedded platforms currently trigger suspend within kernel 
drivers (in response to a button press or some sort of device timeout).

(b) the system designer wants to make sure certain actions are always 
taken regardless of the interface used to suspend (not only in the case 
of a certain application that incorporates these actions and triggers 
the suspend via the standard interfaces at the appropriate time).  For 
example, a user manually enters a command from a shell prompt.

But again, I'll let the embedded system designers jump in here if they'd 
like to add some insight.  In both of the above cases, some ad-hoc 
method of kernel-to-userspace notification could be used, but I am 
trying to gauge interest in using hotplug as a generic notifier for these.

Thanks -- Todd

Re: Hotplug events for system suspend/resume

[Nigel Cunningham]

Hi.

Unless I'm missing something, this will break all existing implementations of 
S3 and S4 because they all freeze userspace processes prior to suspending 
drivers. They do this because they assume it is the responsibility of 
userspace to handle these actions prior to telling the kernel to suspend.

In my mind, this approach is simpler and makes more sense: userspace should 
worry about userspace actions related to suspending before calling 
kernelspace. Kernel space should then only worry about saving and restoring 
driver states and should be transparent to user space. If at resume time, 
some devices have really gone away or appeared, hot[un]plugging events can 
call userspace then.

One other point: If we have userspace calling kernelspace which calls 
userspace, won't we also have to be very careful about not setting up 
feedback loops? (Who knows what userspace will do in response to our unplug 
notification).

Regards,

Nigel

Re: Hotplug events for system suspend/resume

[Todd Poynor]

Nigel Cunningham wrote:

> Unless I'm missing something, this will break all existing implementations of 
> S3 and S4 because they all freeze userspace processes prior to suspending 
> drivers. They do this because they assume it is the responsibility of 
> userspace to handle these actions prior to telling the kernel to suspend.

The patch hooks into the power subsystem prior to freezing processes and 
after unfreezing processes, so I don't think it's a concern (unless 
something is using the power subsystem rather oddly).  This patch sends 
a single notification of system suspend and a single notification of 
system resume, in case there's any confusion with the individual device 
state change notifiers also recently discussed.  It's been run 
successfully on one ACPI system and one non-ACPI system.

> In my mind, this approach is simpler and makes more sense: userspace should 
> worry about userspace actions related to suspending before calling 
> kernelspace. Kernel space should then only worry about saving and restoring 
> driver states and should be transparent to user space. ...

Agreed, with the minor reservations listed in a previous email (suspend 
initiated by drivers must coordinate ad-hoc with userspace, etc.).

I'll let anybody who cares more deeply about this speak up now, 
otherwise this isn't a battle I'll be fighting on behalf of others any 
more.  Thanks -- Todd

Re: Hotplug events for system suspend/resume

[Nigel Cunningham]

Hi.

On Wed, 12 May 2004 12:44, Todd Poynor wrote:
> The patch hooks into the power subsystem prior to freezing processes and
> after unfreezing processes, so I don't think it's a concern (unless
> something is using the power subsystem rather oddly).  This patch sends
> a single notification of system suspend and a single notification of
> system resume, in case there's any confusion with the individual device
> state change notifiers also recently discussed.  It's been run
> successfully on one ACPI system and one non-ACPI system.

Great.

> > In my mind, this approach is simpler and makes more sense: userspace
> > should worry about userspace actions related to suspending before calling
> > kernelspace. Kernel space should then only worry about saving and
> > restoring driver states and should be transparent to user space. ...
>
> Agreed, with the minor reservations listed in a previous email (suspend
> initiated by drivers must coordinate ad-hoc with userspace, etc.).

You're thinking ACPI drivers initiating a suspend? They would do it through 
acpid, wouldn't they? At least that's the glue I use to get my sleep button 
to initiate a suspend. I would assume thermal events would/should work the 
same.

> I'll let anybody who cares more deeply about this speak up now,
> otherwise this isn't a battle I'll be fighting on behalf of others any
> more.  Thanks -- Todd

:> I wasn't meaning to make it a battle!

Nigel

Re: Hotplug events for system suspend/resume

[Todd Poynor]

Nigel Cunningham wrote:

> You're thinking ACPI drivers initiating a suspend? They would do it through 
> acpid, wouldn't they? At least that's the glue I use to get my sleep button 
> to initiate a suspend. I would assume thermal events would/should work the 
> same.

Hi, my main interest is embedded platforms that may or (usually) do not 
implement ACPI.  Therefore, part of what I've been generally driving at 
is that there may be value to adding support for these sorts of 
kernel-to-userspace notifiers in the generic power layer.  As I 
understand it (and I might be behind the times here, please do correct 
me if I'm wrong), acpid reads ACPI-specific power event notifiers, such 
as button pressed, thermal limit exceeded, etc. from the kernel via 
/proc, and acpid executes scripts in /etc/acpi/ to handle the event. 
Some of the embedded developers I deal with have asked for similar 
notifiers in a non-ACPI context.  The system suspend/resume notifiers 
discussed in this thread could be thought of as a general form of "sleep 
button pressed" type event.  (And I now realize it may have been better 
to implement and pitch it as such.)

So, independently of the merits of any particular event notification, it 
may be worth discussing whether there's advantages to using the hotplug 
mechanism for userspace notification and script execution for power 
events, and hooked into the generic power subsystem.  The likely 
alternative is that acpid continues doing things its way and non-ACPI 
systems do something rather different (we already have acpid-like event 
notifiers via sysfs attributes and I'm trying to get rid of them).  Not 
that this ranks among the most pressing of issues facing Linux today, 
but since a generic power subsystem has been created, and since it takes 
some steps toward abstracting away various ACPI specifics, I think 
there's arguably some benefit to taking this particular step as well. 
An acpid-like interface (or even directly adapting acpid) for non-ACPI 
systems is another possibility.

I'd be happy to discuss this further if there's interest.  Thanks -- Todd

Re: Hotplug events for system suspend/resume

[Pavel Machek]

Hi!

> Hi, my main interest is embedded platforms that may or (usually) do not 
> implement ACPI.  Therefore, part of what I've been generally driving at 
> is that there may be value to adding support for these sorts of 
> kernel-to-userspace notifiers in the generic power layer.  As I 
> understand it (and I might be behind the times here, please do correct 
> me if I'm wrong), acpid reads ACPI-specific power event notifiers, such 
> as button pressed, thermal limit exceeded, etc. from the kernel via 
> /proc, and acpid executes scripts in /etc/acpi/ to handle the event. 
> Some of the embedded developers I deal with have asked for similar 
> notifiers in a non-ACPI context.  The system suspend/resume notifiers 
> discussed in this thread could be thought of as a general form of "sleep 
> button pressed" type event.  (And I now realize it may have been better 
> to implement and pitch it as such.)

Well, yes, generic "sleep button pressed" notifier is certainly better
idea. For example it does not have to be synchronous. I actaully like
that.

Is input subsystem any good? It might be as simple as defining keys
for POWER/SLEEP buttons and routing acpi events through even
subsystem...

								Pavel
-- 
When do you have heart between your knees?

Re: Hotplug events for system suspend/resume

[Greg KH]

On Tue, May 11, 2004 at 05:39:45PM -0700, Todd Poynor wrote:
> 
> But again, I'll let the embedded system designers jump in here if they'd 
> like to add some insight.  In both of the above cases, some ad-hoc 
> method of kernel-to-userspace notification could be used, but I am 
> trying to gauge interest in using hotplug as a generic notifier for these.

Ok, I'm not going to accept this until some people who would actually
use it step up and want to push for its inclusion.  None of this "patch
by proxy" stuff...

thanks,

greg k-h

Re: Hotplug events for system suspend/resume

[Tim Bird]

Greg KH wrote:

> On Tue, May 11, 2004 at 05:39:45PM -0700, Todd Poynor wrote:
> 
>>But again, I'll let the embedded system designers jump in here if they'd 
>>like to add some insight.  In both of the above cases, some ad-hoc 
>>method of kernel-to-userspace notification could be used, but I am 
>>trying to gauge interest in using hotplug as a generic notifier for these. 
> 
> Ok, I'm not going to accept this until some people who would actually
> use it step up and want to push for its inclusion.  None of this "patch
> by proxy" stuff...

Sony is one of MontaVista's customers that is keenly interested
in user-space notifiers for power management state changes.
We are interested in uniform handling of power-change events,
in user space, whether they are initiated by other user apps
or from kernel.

Here's one use case:
The system clock usually runs at 30MHz but it needs to run
at at 33MHz when I/O is performed on a particular compact flash
controller (but only when I/O is active).
Here are the state transitions:
         0. System Clock is running at 30MHz
	1. Compact Flash card is inserted
	2. CF controller is activated and detects CF I/O type
	3. kernel notifies that CF I/O is now activated, to
	user-space PM policy manager
	4. User-space PM policy manager changes the clock speed to 33 MHz

Here is another case, which is similar, but triggered by application
action:
         0. System Clock is running at 30MHz and the I/O mentioned above is
         turned off
	1. An application opens up I/O on the compact flash device
         2. device driver turns on the I/O, but cannot get operational
         state.
         3. kernel notifies that the CF I/O is now activated, to
	user-space PM policy manager
         4. user-space PM policy manager changes clock speed to 33MHz

Pardon the delay in responding, but these things take time to
translate, distill and pass on, in international organizations.
(And I'm still not sure I got the details right here, please bear
with me.)

Sony has experience with notifiers using /proc in a 2.4 kernel, so
I don't know if we can directly comment on the details of a hotplug-based
notification scheme.  But I can say that kernel-to-user notifications
is an important feature for us.

I hope this is helpful.

=============================
Tim Bird
Architecture Group Co-Chair
CE Linux Forum
Senior Staff Engineer
Sony Electronics
E-mail: Tim.Bird@am.sony.com
=============================

Re: Hotplug events for system suspend/resume

[Greg KH]

On Thu, May 13, 2004 at 03:46:12PM -0700, Tim Bird wrote:
> 
> Sony has experience with notifiers using /proc in a 2.4 kernel, so
> I don't know if we can directly comment on the details of a hotplug-based
> notification scheme.  But I can say that kernel-to-user notifications
> is an important feature for us.

I don't see anything in your use cases that will not work with the
current interfaces in 2.6.  If not, please let us know.

> I hope this is helpful.

It is, I hope the embedded developers will start to interact with the
kernel community more so than they currently are.

thanks,

greg k-h

Re: Hotplug events for system suspend/resume

[Pavel Machek]

Hi!

> >I still do not see the need for this.  As a user, you caused the
> >suspend/resume event to happen, why get notified of it again?  :)
> 
> The idea is to notify the "power management application" of impending 
> suspend and just-completed resume, regardless of who or what asked for 
> the suspend.  Actions taken at suspend might include dropping network 
> connections and saving application state to stable storage.
> 
> The reasons for which this was requested of me as a kernel-to-userspace 
> notifier, that I am aware of, are:
> 
> (a) some embedded platforms currently trigger suspend within kernel 
> drivers (in response to a button press or some sort of device
>timeout).

I believe kernel should userspace "button was pressed", and let
userspace ask it for suspend.

> (b) the system designer wants to make sure certain actions are always 
> taken regardless of the interface used to suspend (not only in the case 
> of a certain application that incorporates these actions and triggers 
> the suspend via the standard interfaces at the appropriate time).  For 
> example, a user manually enters a command from a shell prompt.

User should not manually do "echo something > /proc/acpi/sleep". For
embedded platforms, it should be rather easy to ensure user does not
do that, right?

OTOH, it might make sense to define that /etc/rc.d/suspend/* has to be
run before suspend and /etc/rc.d/resume/* has to be run after suspend;
by whoever who does suspend.

suspend-vetoing is pretty bad idea if your battery is running down. I
believe shutdown does it right: kill -15 -1; sleep 1; kill -9
-1. I.e. let apps know one second before suspend, but do not let them
veto it.
								Pavel
-- 
When do you have heart between your knees?

RE: Hotplug events for system suspend/resume

[Grover, Andrew]

> > > In my mind, this approach is simpler and makes more 
> sense: userspace
> > > should worry about userspace actions related to 
> suspending before calling
> > > kernelspace. Kernel space should then only worry about saving and
> > > restoring driver states and should be transparent to user 
> space. ...
> >
> > Agreed, with the minor reservations listed in a previous 
> email (suspend
> > initiated by drivers must coordinate ad-hoc with userspace, etc.).
> 
> You're thinking ACPI drivers initiating a suspend? They would 
> do it through 
> acpid, wouldn't they? At least that's the glue I use to get 
> my sleep button 
> to initiate a suspend. I would assume thermal events 
> would/should work the 
> same.

Yeah. There definitely is a need for userspace apps to be power-aware,
and have the ability to prevent suspend, but I think this should all be
done via the daemon (talking to apps via D-BUS?) and then the daemon
pulls the trigger if all power-aware apps in userspace agree it's OK. I
don't think ACPI kernel code should do anything without being told to.

The kernel sleep interface should only ever be used by the daemon. If
the user decides to use it from the cmdline then things aren't going to
work right.

My 2c,

-- Andy