Better integration with power management scripts

[Holger Macht]

On Mi 26. Apr - 22:43:18, Richard Hughes wrote:
> On Wed, 2006-04-26 at 18:55 +0200, Holger Macht wrote:
> > 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...
> 
> Been busy with other stuff, sorry. I need to fire off a load of emails
> to ppl about asking people to register to the list.

No problems in general that there are no mails yet, but I have problems
with a discussion that goes on on hal which actually belongs to pm-utils.

> 
> > > 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?
> 
> Ahh, I think pjones wanted something that worked here and now, although
> my personal preference would have been to do this file-by-file.
> It does make sense keeping the history I guess, and gives us something
> to build on.

But the way "want something that workes here and now" is definitely the
wrong way. Because we have that already ;-)

It's also my prefered way to do the design in first place. So for the
intention to be a community project, can we start from scratch again?

> 
> >  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.
> 
> See above, apologies.

Ok.

> 
> > 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.
> 
> Yup, agreed.
> 
> > 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.
> 
> I don't like the idea of pm-utils doing anything clever. They should be
> *really* simple.

But we should provide the needed infrastructure to people which like to
make things clever.

> 
> > 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...
> 
> Ears open.
> 
> > 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.
> 
> I don't think we have to. Telling the user that the suspend failed
> because module xyz failed to unload isn't useful. It should just work.

Of course it should just work, but it doesn't ;-)

The thing with fialed module was just one example. Two years ago we also
didn't have that infrastructure, and more and more things arised that
showed that it is helpful. So wouldn't it be possible to add the
infrastructure for that? Something like the following in the base function
set?

notify_user() {
    $BIN_DIR/dbus-send --system --print-reply \
	--dest=org.freedesktop.PowerManagement.SuspendMessage \
	org/freedesktop/PowerManagement/SuspendMessage/ \
	org.freedesktop.PowerManagement.SuspendMessage \
	string:"$1"
}

Or at least a defined location to give the possibility for
distributions/vendors to add it. But I think it would make sence to add it
by default. If anything goes wrong, the script writer simply has to call
notify_user("<any propriate message"). And applications can ignore them if
they want.

> 
> >    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...
> 
> How long does modprobing a few modules take? pm-suspend takes an small
> about of of time on my system, the largest delay being on the first
> sync, which takes less than a second.

Well, the things we do need about 2 seconds, but I said already that this
is just a "nice to have" feature. What bothers me more is how you would do
a graphical bootsplash or the like for suspend2 without any progress
information. So what about seperating the suspend/resume into different
stages or doing something similar like the above:

progress() {
    $BIN_DIR/dbus-send --system --print-reply \
	--dest=org.freedesktop.PowerManagement.SuspendProgress \
	org/freedesktop/PowerManagement/SuspendProgress/ \
	org.freedesktop.PowerManagement.SuspendProgress \
	int32:$1
}

It is simply to add this function call in different places or again,
provide the infrastructure for others adding it.

> 
> >    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.
> 
> I don't think this belongs in the HAL or pm-utils layer IMO. It might
> belong in powersaved or gnome-power-manager but certainly not in
> pm-utils.

We also don't have that for some time now but experienced that there are
situations were need the knowledge of the helper scripts to ask valuable
questions. And it would make things easier for vendors to do clever things
if we provide them with the proper infrastructure.

> 
> >   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.
> 
> I really think dbus is too complicated for these incredibly simple
> scripts.

It would only be some dbus-send calls, not very complicated, see above.

> 
> > 
> > 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.
> 
> I'll look tomorrow, as today has been one hell of day! Thanks for the
> pkg tho.
> 
> > So let's try to work together to find a good solution.
> 
> Yes, but give me a couple of days to look through your scripts, and then
> we can bash out some details of stuff that needs to change.

No problem, but for accomplishing that, the other discussion on Hal should
just stop, otherwise there will be too much code already to do design
changes.


Regards,
	Holger