Better integration with power management scripts

[Holger Macht]

On Sun 23. Apr - 23:02:25, Richard Hughes wrote:
> On Wed, 2006-04-19 at 18:47 +0100, Richard Hughes wrote:
> > * Perhaps apply for freedesktop for the project...
> 
> Which I've done, as the general consensus was this shouldn't be hosted
> by any one $VENDOR.
> 
> If you are interested, please subscribe to this list:
>
> http://lists.freedesktop.org/mailman/listinfo/pm-utils
>

I did, but no mails so far...
 
> a list for the *sole purpose* of developing these little weedy scripts
> that do clunky things. Nothing is going to be imported or checked in,
> until we have a quick design draft that we can all work with.

This would be great indeed. But why are there already things imported
before this happended? And why are there posts about this topic on the HAL
list excluding the pm-utils at lists.freedesktop.org list? And not one single
mail on that independent list so far. So please continue discussion on the
new list and ping the authors of the different existing projects to give
them at least chance to get involved.

But now let me start to say what I actually want...

As a general statement, I don't like these scripts to reside in HAL.

But...
this seems to be the way most people like to go, although not all people
involved in power management read the HAL list. SUSE, respectively me,
likes to definitely avoid a situation in the future where HAL has one way
of doing things and the powersave daemon/SUSE has another one. The common
goal should be to have one solution which fits everybody's needs and
that's definitely something we agree in.

So...
I (or we) will try to work together with you to find and create this
common solution. It's a hard decision for me, but I'm willing to go this
way. But It's only possible if you really keep your promises: Let this
discussion and implementation take place on an independent list and don't
import or create anything before everybody agrees with it or, at least, is
able to life with it. For this reason I've CC'd this new list. Otherwise
we will again end up in a situation were we fight each other.

One thing that bothers me is that you try to do things completely
new. There are already good working and good designed solutions like the
so called hibernate scripts or the scripts which come along with the
powersave daemon. We already planned to merge our solution with the other
existing ones and now I think is the time to do this merge and create this
new project pm-utils.

What we decided yesterday was to provide you with a rough description of
our design and the different scripts we already use to do these suspend
things. I really think that they are useable and modular/extendable to use
parts of them in the future. What we tried over the last month was to make
them really distribution independent and configurable, removing all
hardcoded paths (like /etc/pm) etc.

Therefore I will do this rough overview now and hopefully it is
helpful. It's important to mention that I definitely do not want to say
something like: "Please take our solution!". But these have proven about a
long time to be useable, so I think parts of them are also useable for
pm-utils. Some things maybe outdated and were just there for hitorical
reasons and there are also things that maybe done better, but I hope you
get what I'm trying to say...

General design
==============

  We separated the suspend into three steps. Preparing (stopping services
  etc.), doing the suspend (echo [state] > /sys/power/state) and restoring
  the system to it's original state.

  We also have some possibilities to communicate with the desktop/user or
  any other application:
   
   1. Send a message over dbus about a notice, a failure or an
      error. There's definitely the possibility that _something_ goes
      wrong during preparation of the suspend. For example "Failed
      unloading module xyz because device is still in use". That's just
      one example, but IMO there might definitely arise something like
      that. Maybe we add a dbus interface like
      org.freedesktop.PowerManagement.SuspendMessages or the like which
      applications can listen to show these messages to the user.

   2. Send messages over dbus to report the current progress of the
      scripts. In our case, we show a progress bar in kpowersave shortly
      before suspending which says something like "unloading module xyz"
      or "stopping service xyz". For this purpose we added some progress()
      fuction calls to our scripts in different places. That's just a nice
      to have feature but in general it might be valuable. Maybe we can
      seperate the suspend cycle in different stages like NetworkManager
      does. This would also be needed for any graphical bootsplash to show
      this. Something like org.freedesktop.PowerManagement.SuspendProgress
      comes to my mind...

   3. For user interaction, we need a possibility to ask questions. Just
      some simple examples like "do you really like to suspend although
      there are other users logged in" or "really suspend? There is a CD
      buring job running". That's not yet in our scripts but is something
      we should have in mind for the future.

  It would be easy to have a function notify_user() or progress() which
  does a dbus-send or looks into a directory if there is a script to
  execute for this purpose. All this is something we have already and it
  would be hard for us to have a regression in this area because it's
  something our users really appreciate.


Summary of most important and noteworthy script parts we currently have:
========================================================================

I put a tarball with all the scripts regarding suspend to
http://powersave.sf.net/powersave-sleep-scripts.tar.bz2 to make it
possible for everybody to have a quick look without the need to download
the whole powersaved tarball which these scripts are usually part of.

helper_functions:

  Mostly general stuff like setting paths and adding debugging
  functionality which we will definitely need IMO. For example, there is a
  function 'DEBUG' to log to /var/log/messages with regard to priority.

  Additionally it contains communication with the daemon which you can
  silently ignore.

sleep_helper_functions:

  This script is sourced by every script that does either suspend to disk
  or suspend to ram and contains common functiones shared by every sleep
  method. It's mainly what is needed for suspend to ram or standby. Only
  suspend to disk has some additional hooks.

  1. Define statefiles to record the system state in the moment we enter
     sleep to only resume/recover the needed parts.

  2. Define logfiles like /var/log/suspend2disk.log for debugging
     purposes.

  3. Set dynamic paths to some binaries.

  4. Functions like:
      unload_module(), set_variables() for reading the configuration,
      prepare_logs() or prepare_sleep() and restore_after_sleep().

prepare_suspend_to_disk:
  Doing specific stuff which is relevant only for suspend to disk. Of
  course, not everything is needed compulsory.

   - configure grub
   - activation of resume device
   - check if a correct resume= parameter is given on the commandline,
     otherwise fail the suspend
   - set the shutdown method platform/shutdown dependent on the
     configuration
   - set the image_size
   - switch vt's if needed
   - etc...

restore_after_suspend_to_disk:
  Restore the system to its original state after resume.

prepare_suspend_to_ram/ restore_after_suspend_to_ram:
  Mainly what's in sleep_helper_functions.


So let's try to work together to find a good solution.


Regards,
	Holger