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. _______________________________________________ Pm-utils mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pm-utils
