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

[Stefan Seyfried]

On Thu, Apr 27, 2006 at 11:25:33AM -0400, David Zeuthen wrote:
 
> 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

ok.

>     put the reason in a file in /tmp. Then our HAL handler (which is

Not /tmp, for security. But we will find another directory (/var/run
or /var/lib come to mind) where we can put it.

>     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

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

ok.

In fact the "put the reason for the failure in a well defined location"
might even be enough for notification - the user-visible tool can read it
from there. Primitive but effective ;-)

> 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

I was astonished how long windows takes to resume from RAM on one of my
notebooks - i had not tried it for years - but this is OT here ;-)

> 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

Yes, this should be sufficient, and additionally...

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

... if no such gizmo is installed, it does not hurt.
... and users can abuse it for small, clever hacks. I especially like that
    part ;-)
 
> Would this work for you?

It sounds good.
 
> >   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. The more i think about it, the more sense it makes.

Our "desire for interaction" might just have historical reasons, because
when we started powersaved, there was no HAL and no desktop-support for
"unmount all external drives", modules just needed to be unloaded to make it
work _at all_ etc. So we needed interaction. And in fact all the time one
of our TODOs was 'better interaction in case of problems'. But now, with the
desktop support for mount and unmount and generally a better kernel and
infrastructure support, it might in fact be something that no longer needs
to be implemented at the low level we had it before. So i think we can do
without the "interaction" feature, as long as feedback for errors is possible.
-- 
Stefan Seyfried                  \ "I didn't want to write for pay. I
QA / R&D Team Mobile Devices      \ wanted to be paid for what I write."
SUSE LINUX Products GmbH, Nürnberg \                    -- Leonard Cohen