[Pm-utils] Re: Dealing with suspend/resume failures

Holger Macht hmacht at suse.de
Mon Nov 13 10:40:01 PST 2006

On Mon 13. Nov - 12:57:06, David Zeuthen wrote:
> Holger Macht wrote:
> >Additionally, can we let pm-utils return one descriptive message about the
> >reason for the failure, if one is present? Nothing very verbose, just
> >something like 'Module xz failed to unload' (just an example, of
> >course). This would be something that can be shown to expirenced users.
> Certainly, I'm not opposed to that, patches welcome. Synchronous failures, however, are not very common

This reason would still be in the logfile which stores the state of the
system, such as lsmod. It's just a summarization about what went wrong
that in case pm-utils knows the exact reason why it failed.

> >Yes, we should definitely add a HAL method to get the output.
> There's a small technical obstacle insofar that method calls on the non-standard interfaces on HAL implemented by 
> running a binary can only returns integers (not true for addons, they can return anything they want). This is 
> probably something that is fixable though. I'll look into this.

Ok, good.

> >We should definitely use the pm-utils logfiles for this. I will send a
> >logging hook to the pm-utils list in a few minutes.
> The stuff in HAL will still write a preamble (with e.g. /sbin/lsmod output) and possibly a postamble too. I think 
> that belongs in HAL, not pm-utils, because HAL provides the asynchronous error handling, pm-utils does not.

But if it would be done in pm-utils, pm-utils would also useable without
HAL, so it would be some kind of separate. HAL would only be the interface
between the desktop and pm-utils.

Can't we agree on a preamble and postamble pm-utils writes to the log?


More information about the Pm-utils mailing list