Problem Suspending on Debian Etch

Richard Hughes 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
> swsusp2_15

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. 

Agree.

> 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 :-)

Richard.



More information about the hal mailing list