[Pm-utils] Why do we still ship hal-system-power-pmu / PMU support suboptimal in pm-utils
cardoe at gentoo.org
Mon Dec 3 16:01:22 PST 2007
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.
> 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 . Apparently this has
>>>> led to problems  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
>>> 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.
Bring pm-utils back to life and I'll agree with you Richard.
Doug Klima <cardoe at gentoo.org>
More information about the Pm-utils