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

[Doug Klima]

Richard Hughes wrote:
> 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?

It brings the benefit of not having a totally broken package. pm-utils 
is all but dead upstream. I made several requests and they went 
virtually unanswered. I even had to do all the leg work of getting 
pm-utils.freedesktop.org registered as a web host when I requested some 
sort of data. This is the only e-mail to the ML in 3 months. It's 
YARHTTGABFBOP. Yet Another RedHat Technology That Gets Abandoned But 
Forced By Other Packages.

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

Big distros defined as Red Hat / Fedora only?

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

mm on the contrary I've heard a lot of success stories with userspace 
stuff when kernel stuff failed.

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

Bring pm-utils back to life and I'll agree with you Richard.

-- 
Doug Klima <cardoe at gentoo.org>
http://dev.gentoo.org/~cardoe/