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

[Stefan Seyfried]

On Mon, Dec 03, 2007 at 09:56:48PM +0000, 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?

A "noarch" package save space on CDs, servers, ... It is generally
considered a good idea among package maintainers to have as many
architecture-independent packages as possible.
 
> > > >  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.

Define "most distros". At least debian and openSUSE don't do it that way, and
i'd consider debian as pretty big and pretty important.

Understanding s2ram is not really that hard. And it reduces the complexity
by a fair amount, just by removing the external dependencies from radeontool
and vbetool and, more important, by making suspend much more reliable, since
you can e.g. prevent users from switching back to X while vbetool still posts
the card (which can take quite some time on some BIOSen).
Following your argument, you should also rewrite HAL as a bunch of shell
scripts.
 
> > 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.

For s2both?
;-)

Yes, i also have few reports of userspace suspend failing, and kernel
suspend working, but also the other way round. And yes, splash support
has still room for improvement.

There are also other benefits of userspace suspend, namely image compression
which speeds up resume usually by a factor of two.

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

You obviously never had a machine that crashes if you switch back to X
while vbetool is POSTing the graphics card. But those exist, and some users
_do_ press "alt-F7" if there seems to be no progress for two seconds during
resume.

What we are asking is to make the usage of the suspend package optional
in upstream pm-utils. Right now at least 4 distributions are using patched
packages to achieve this. Having a single, common infrastructure was the
goal when pm-utils were created.

And even if this was intended as "have the whole world use the redhat way",
it is not how it was announced. If you want it that way - just say so.

Best regards,

	Stefan

-- 
Stefan Seyfried
R&D Team Mobile Devices             |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg  | "Well, surrounding them's out." 

This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)