[Pm-utils] Re: Better integration with power management scripts
hughsient at gmail.com
Wed Apr 26 14:43:18 PDT 2006
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.
> > 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.
> 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.
> 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.
> 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.
> 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
> 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.
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.
> 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.
> 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
> 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
> 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
> 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.
More information about the Pm-utils