[Pm-utils] Release?

Michael Biebl mbiebl at gmail.com
Sun Mar 16 14:52:39 PDT 2008


2008/3/16, Victor Lowther <victor.lowther at gmail.com>:
> On Sun, 2008-03-16 at 18:31 +0100, Michael Biebl wrote:
>  > 2008/3/16, Victor Lowther <victor.lowther at gmail.com>:
>  > > On Sat, 2008-03-15 at 18:16 -0500, Victor Lowther wrote:
>  > >  > On Sat, 2008-03-15 at 23:43 +0100, Michael Biebl wrote:
>  > >  > > 2008/3/15, Victor Lowther <victor.lowther at gmail.com>:
>  > >  > > More bugs:
>  > >  > > Running pm-is-supported as not root:
>  > >  > >
>  > >  > > # pm-is-supported --suspend && echo yes
>  > >  > > mkdir: cannot create directory `/var/run/pm-utils/storage': Permission denied
>  > >  > > yes
>  > >  > > # pm-is-supported --help
>  > >  > > mkdir: cannot create directory `/var/run/pm-utils/storage': Permission denied
>  > >  > > pm-is-supported [--suspend | --hibernate | --suspend-hybrid ]
>  > >  >
>  > >  > Fixing that the right way will be slightly tricker.  I will postpone
>  > >  > looking at this until tomorrow --  I have a party to get ready for.
>  > >
>  > >
>  > > Fix comitted and pushed upstream.  Now we only try to parse blacklist
>  > >  entries and load default parameters after we have taken the suspend
>  > >  lock.
>  >
>  > Hm, seems I missed to review your vlowther-dynamic-hook-disable changes.
>  > Honestly, I'm a bit sceptical about adding this new /etc/pm/parameters
>  > and /etc/pm/blacklists interface.
>  >
>  > We already have a (documented) mechanism for users to disable a hook
>  > (which is, to create a non-executable file in /etc/pm/sleep.d/. Why do
>  > we need another mechanism?
>
>
> The hook-disabling mechanism is not primarily for users -- it is for
>  modules and other hooks.  I added the blacklist-parsing code because it
>  is a bit more intuitive than masking out a system hook by creating a
>  nonexecutable file.

Still, we have two ways now to do exactly the same, which is not good imho.

>
>  > Second, do we really need to pass parameters to hooks? I haven't
>  > needed it so far. Imho we should only add functionality which is
>  > actually used.
>
>
> I use it.  If I don't pass --quirk-none (or mask 99video out using a
>  blacklist entry or a nonexecutable hook), then the paramaters hal passes
>  to pm-suspend will hardlock my system on reboot everytime when it tries
>  to POST the card.  HAL currently does not take the video card and video
>  driver into account when deciding which quirks to pass to pm-suspend,
>  and until it does I will need this sort of functionality.

We already have /etc/pm/config.d. Why don't we utilise it for that purpose:
Let's define a new variable  PARAMS (better name welcome) which get's
appended to PM_CMDLINE. That way you can drop a config file into
/etc/pm/conf.d/myopts.

We could do the same for the blacklisted hooks. We simply define (and
document) a variable DISABLED_HOOKS, which can be set via
/etc/pm/config.d

I don't think we need special code for these two cases.

Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


More information about the Pm-utils mailing list