Re: Hotplug events for system suspend/resume

From: Pavel Machek
Date: Mon May 17 2004 - 08:24:11 EST


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?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/