[Pm-utils] [RFC] [patch review] Hook independence and security fixups, part 1

[Victor Lowther]

On Feb 2, 2008 5:44 PM, Till Maas <opensource at till.name> wrote:
> On Sun February 3 2008, Victor Lowther wrote:
> > On Feb 2, 2008 5:19 PM, Till Maas [...] wrote:
> > > On Sun February 3 2008, Victor Lowther wrote:
> > > > On Feb 2, 2008 4:55 PM, Till Maas [...] wrote:
> > > > > What is the "inhibited" argument used for? (I do not know why there
> > > > > is the INHIBIT variable/file in the current pm-utils btw.) But at
> > > > > least here it seems enough to not run the file instead of giving it
> > > > > the argument "inhibit".
> > > >
> > > > Debugging -- it makes the system do everything except actually
> > > > sleep/hibernate/whatever.
> > > > Useful for testing hooks, or testing to see if whatever bizzare
> > > > suspend issue is a pm-utils issue or a kernel issue.
> > >
> > > Are you sure here? In the latest pm-utils release, the INHIBIT file was
> > > deleted before the hooks were run. I now got a sudden inspiration. I
> > > guess it was once used to make it possible for hooks to show that they
> > > want to avoid hibernation/suspend, e.g. because something that is needed
> > > to hibernate did not work. I guess in case this is the use case, a
> > > special return value for the hooks would be better to signal abortion,
> > > because then the later hooks would not need to be run.
> >
> > And if you add a hook that has, say, "touch "${INHIBIT}"...
>
> Yes, but you also need to source the functions file, and it is not a straight
> forward approach to do this imho.

Eh, so it goes from being a two-line script to a three-line script.

I am more interested in hearing feedback on the larger aspects of this
patch series -- other than the inhibit business, are there any flaws
in this that I need to rethink?

> > I currently have the system rigged to use exit values to signal that
> > we can skip running this hook on wakeup, but adding in a return value
> > that signals that we should abort the process would be easy enough.
> >
> > > But for debugging it would be helpful to have a variable that is
> > > evaluated, e.g. PM_SKIP_ACTION or something similiar.
> >
> > we could, but the current system works well enough.
> >
> > > Btw. did you intentionally answer me via a private mail?
> >
> > No, it was an accident.
>
> Regards,
> Till
>