[Pm-utils] Why do we still ship hal-system-power-pmu / PMU support suboptimal in pm-utils

[Richard Hughes]

On Mon, 2007-12-03 at 10:51 +0100, Stefan Seyfried wrote:
> On Sun, Dec 02, 2007 at 06:45:03PM +0000, Richard Hughes wrote:
> > On Sun, 2007-12-02 at 10:00 +0100, Michael Biebl wrote:
> > > I have to add, that pm-utils in Debian does not ship pm-pmu (it was
> > > removed by the Debian maintainer deliberately), as we tried to make
> > > pm-utils an arch:all package (only shell scripts)
> > 
> > Please don't do this.
> 
> care to give a reason? I think this is very reasonable.

What benefit does it bring?

> > >  and provide the pmu
> > > functionality (together with support for all the other quirks) in one
> > > single binary
> > 
> > No, that's no how it is supposed to be put together.
> 
> Why?

Because that's how it's put together on most of the big distros - and
more often that not it works, and most importantly people understand how
it works.

> > > , s2ram from the uswsusp package [2]. Apparently this has
> > > led to problems [3] for people using pm-utils, but don't have the
> > > uswsusp package installed.
> > 
> > Why do you need to use pm-utils and uswsusp? Doesn't the kernel method
> > work? It sounds like this is packaged in an odd way.
> 
> The kernel method is slow and has no support for splash screens. You cannot
> do s2both with it.

I've never got the userspace splash fb to work on most of the systems I
was testing at RH. It sometimes broke working suspend. I've got nothing
against userspace suspend, it just seems kernel suspend seems to work
for more people.

> > > The question now is, where to put this pmu support: hal, pm-utils or s2ram?
> > > I personally would like to remove hal-system-power-suspend-linux from
> > > hal, pm-pmu from pm-utils (so pm-utils becomes a arch:all shell script
> > > only package) and move all the nasty stuff into one binary, s2ram,
> > > which then deals with stuff like poking /dev/pmu, VBE save/restore
> > > etc.
> > 
> > No. s2ram should just _do_ the suspend, not muck about with quirks and
> > poking pmu - the pm-utils infrastructure should do this. The "nasty
> 
> i absolutely disagree. The only advantage that you get by doing it in
> ugly shell scripts is that you pull in lots of dependencies and are
> more susceptible to race conditions. Putting all the quirks into one
> binary (which should probably even be mlock()ed) makes suspend much
> less error prone.

I don't think this is true at all.

Richard.