Better integration with power management scripts

[Holger Macht]

On Thu 27. Apr - 08:40:46, Richard Hughes wrote:
> 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 .

It's of course ok to CC other lists, but pm-utils should not be excluded ;-)

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

Yes, but there are other possibilities already working and we should have
started to find which one to start with together.

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

You will get the help of everybody as long as there are no commits which
weren't discussed before.

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

Not discussed on pm-utils, but I follow hal@, too.

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

Fine.

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

That would be good.

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

Yes, of course. It was just a copy & paste from our scripts. I would like
to see a dbus signal which any application can listen to or even claim
this object so that there is always only one application that cares about
displaying those messages. So for the future we could make powersaved or
gpm or kpowersave to claim that object and it cares about displaying this
message, also without X in case of a system daemon.

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

Yes, but it should be possible to drop scripts somewhere for the different
stages. For example a directory prepare_suspend, one do_suspend and one
restore_after_suspend. The namings are just examples.

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

Yes, it's a signal that best fits. copy & paste error without thinking,
see above.

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

I would it see that pm-utils does the basic stuff and provides
infrastructure and vendors/distributions can add their weird, clever,
complicated whatever stuff using the basic 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.
> 
> I think they have to be signals, rather than methods, see above.

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.

But for me, the decision which initial framework should be chosen should
be discussed _before_.

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

Regards,
	Holger