Problem Suspending on Debian Etch
hughsient at gmail.com
Wed Sep 27 11:09:06 PDT 2006
On Wed, 2006-09-27 at 19:59 +0200, Tim Dijkstra wrote:
> Op Wed, 27 Sep 2006 16:44:00 +0100
> schreef Richard Hughes <hughsient at gmail.com>:
> > On Wed, 2006-09-27 at 17:16 +0200, Tim Dijkstra wrote:
> > > > I would *love* for debian to start shipping pm-utils.
> > >
> > > I understand it's going to be a dependency of hal, but what is so
> > > wonderful about it?
> > > I just browsed a bit through webcvs, but it seems to be a framework
> > > and a bunch of scripts with similar purpose to hibernate (the
> > > suspend2 tool), but than with much less functionality...
> > In what way? It's designed to be very flexible so that distros and
> > vendor products can just drop in a single file and assume it "just
> > works" on all platforms and distros.
> Well, I must confess, I don't use all those hibernate knobs that much,
> but it can do lots of stuff:
> $ ls /usr/share/hibernate/scriptlets.d/
> acpi_sleep filesystems misclaunch pcmcia
> sysfs_power_state bootsplash grub modules
> programs ususpend clock hardware_tweaks modules_gentoo
> remount_xfsboot vbetool devices lilo network
> services xhacks diskcache lock newkernel
> suspend2 xstatus fbsplash lockfile pause_audio
Yup, and I'm guessing with some tweaking some of those scripts could be
used by pm-utils - and then all distros and users would get all those
fixes rather than those that just hibernate. Also, packages such as grub
could install the "grub" file themselves, rather than pm-utils providing
all and for everything that might or might not exist.
Also, I'm a little worried by the files marked "hardware_tweaks" and
"misclaunch". These are very hackish IMO.
> > > Apart from that it seems to assume build in software suspend, no
> > > possibility to use userspace software suspend or suspend2.
> > That can be fixed trivially if required - and we really don't want to
> > support userspace software that is likely to replicate all the generic
> > work pm-utils does.
> Some things can only be done in the binary that does the userspace
> suspend; it can be the only user space program during freeze. I'm not
> sure which generic things you mean...
Well, if we can just call one file "foo" to suspend then we are good to
go - if "foo" starts stopping services and syncing time (and all the
stuff pm-utils should do) then we are less fine.
> > > In other
> > > words, I don't think it's ready to be a dependency of hal, the
> > > current setup seems better.
> > The mish-mash of looking for specific scripts to run on different
> > distros? All the distro suspend projects seem to be re-inventing the
> > wheel - i.e. run simple random stuff at suspend and resume - simple as
> > that.
> Well, I should have worded it differently. I'm not saying that having
> several distro's/projects reinventing the wheel is a great thing. It
> would great if people could standardize on something.
> pm-utils surely has the ambition to become that standard script-suite,
> and probably will come a long way because hal will depend on it, but
> looking at cvs, it just seemed to be the next kid on the block. (I now
> realize you're one of the authors and may have stepped on some toes;)
No worries - debate is always good. :-)
> I just wanted to say that the state it is know in will have lots of
> people loose functionality during hibernate.
Chicken and egg. Until distros and users start using pm-utils then we
won't be able to add the new-sane stuff. The insane stuff we should let
individual users add as required :-)
More information about the hal