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

[Holger Macht]

On Do 27. Apr - 11:25:33, David Zeuthen wrote:
> On Wed, 2006-04-26 at 18:55 +0200, Holger Macht wrote:
> > 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.
> 
> Well, there's 250+ people subscribed to the hal list. I don't really
> think anyone wants Yet Another Mailing List to subscribe to. Plus, I
> want pm-utils to be so simple that it's done to everyones satisfaction
> in a few weeks and we never need to change it from there. So I'm not
> really sure we need another list, but Richard created one anyway... I
> say we keep it on the hal list for practical reasons.

You know what controversy currently exists in regard to power management
and HAL. And I liked the idea of starting a new project, leaving
everything behind what has been and trying to find a proper solution for
the future. I would also appreciate to see other power management guys
invited to get involved. At the power management summit this year, we
decided to create a new list to go that way for everything related to
power management in userspace, not only suspend. And I liked this idea. Of
course, pm-utils@ is only for suspend, but the general approach applies
here, too.

> 
> 
> > 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.
> 
> Yes, with the underlying theme that things should be kept very simple. I
> don't want pm-utils to export any D-BUS services itself but providing
> infrastructure for this is fine with me. The only use of D-BUS in
> pm-utils proper should be to ask HAL to resume the video cards (and
> gracefully work if HAL is not available, e.g. no timeouts). That's it.

Ok.

> 
> >    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.
> 
> So, I think my point of view is basically this: If a user knows what
> "Unloading module xyz because device is still in use" means he also
> knows to look at the syslog. I basically think it's about us realizing
> what users we are designing for. I realize this point of view may be
> GNOME contric and e.g. KDE centric distributions might want to put up
> such messages for whatever reason. They should have that freedom but I
> shouldn't make pm-utils a lot more complicated.

But without any information system, the user maybe does not even know that
he should look into syslog. You click suspend, and... nothing happens. We
had that, and the feedback we got inspired us to change it. So I think you
understand that I wouldn't like to see a regression in this area. And I
agree with you that "unloading module... failed" might be to technical for
desktop distributions.

> 
> So I think we need to do this
> 
>  1. pm-suspend and friends needs to return errors in a standardized
>     format, e.g. predefined set of error codes. Also, they should
>     put the reason in a file in /tmp. Then our HAL handler (which is
>     hal-system-power-suspend) can interpret these return codes and throw
>     the right exception. For example we might define the exception
>     org.freedesktop.Hal.Device.SystemPowerManagement.LKMFailedToUnload
>     with where the textual part of the exception is the name of that
>     Loadable Kernel Module. Implementation-wise the HAL handler simply
>     checks the return code (it may be 5 for LKMFailedToUnload) from
>     pm-suspend and reads /tmp/pm-utils-failure-reason for the name of
>     the LKM

Well, sounds a little bit too complicated for me instead of having an
interface org.freedesktop.Hal.SystemPowerManagement.SuspendFailure the
pm-utils script emmits signals over with two arguments, a return code and
an optionl variable string, e.g. int32:5 string:<the module name>. In case
hal does not exists, pm-utils scripts still can write this information to
/tmp or syslog. It's just a function which determines if Hal is available
or not when the scripts are started.

But I can also life with your solution.

> 
>  2. No matter what pm-utils should log useful failure to syslog this
>     both users, admins and developers are going to look in that
>     location. So in the event an LKM fails to unload we simply also
>     put an error there.
> 
> How about that?

Yes, sound good, not only for a rmmod failure, but also for other things
that _might_ go wrong. Hopefully there will never be such situations ;-)

> 
> >    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...
> 
> You know, obviously the right fix is to make suspend very fast (and
> Windows and Apple shows us this can be done) and I still think you don't
> know who you are designing for if you want to bother the users with
> technical jargon. Also, I really really don't want pm-utils to send out
> D-BUS signals by itself.

Yes, suspend preparations should be really fast and they are in
general. And as mentioned above, that's nothing I really _want_. It is/was
just "nice to have" in powersaved and I surely can abstain from it in
pm-utils.

And in regard to the information provided to the desktop (which is
something I like to see), you can always reword technichal problems so
that the user can dael with it.

I don't really see where the problem is to have a function that either
does a dbus-send if available and/or does something else. IMO, it would be
even cleaner, but this should not be come a showstopper ;-)

> 
> But it would be fine with me if it did something like
> 
>  notifiers="/etc/pm/notifiers/*"
>  for n in $notifiers; do
>    [ -x $n ] && $n <what we are doing now> <more detail>
>  done

Something the like I mentioned in my (3.) section. So ok with me and while
thinking about it a little more, I think it's the best solution which
makes it really extendable.

> 
> Then for example all the KDE or SUSE UI gizmo for showing progress can
> install a handler that sends out a message. It might even want to use
> DCOP, who knows :-)

I just read over the "SUSE UI gizmo" for now.

> 
> Would this work for you?
> 
> >    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.
> 
> As Matthew points out this should be handled by the power management
> daemon, e.g. powersaved or gnome-power-manager or whatever. 
> 
> Do you agree?

Basically, yes.

But I still fear that applications won't have enough knowledge to handle
this. But with the "notifiers directory solution", should be possible.


Regards,
	Holger