[Pm-utils] Re: Better integration with power management scripts

Thu Apr 27 00:40:46 PDT 2006

On Thu, 2006-04-27 at 08:54 +0200, Holger Macht wrote:
> 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.

In my defence, David asked me to include HAL for conversations as many
of the pm developers were already on hal at .

> > 
> > > > 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?

I'm not against starting again, I just think using pm-utils gives up
something to start with, something that we know works.

and, to be honest, pjones makes me look amateur with his use of shell,
and I wanted his help.

Stuff that should be removed in the next few hours:

* the pam stuff, as scripts need to be run as root
* all the display re-init stuff, as this is moving to HAL

> > 
> > > 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.

Sure, I can agree with that.

> > 
> > > 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"
> }

I don't think it's needed for most cases, but I can understand why you
want it. I think this could be in the base functions certainly.

> 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.

Hmm, as long as no blocking is done.

> > >    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:

suspend/resume
hibernate/thaw

should certainly have different stages, but I don't think they need to
be separate files, just different variables values if you like.

> 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.

Shouldn't that be emitting a signal, rather than calling a method tho?

> > 
> > >    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.

Not at the expense of keeping things simple, something we have to do.

Random vendor, say vmware, has to be able to dump a random file in a
pre-defined directory that does *basic* stuff.

> > >   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.

I think they have to be signals, rather than methods, 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.

I think we need to define the initial framework (which was taken from rh
pm-utils) and then say "the way we do 'x' is crap, it's better to do it
this way" -- and then change it -- rather than arguing about a 125%
design that never gets built into a product. That's my opinion tho.

As for the discussion cc'ing HAL, David, what do you think?

Richard.