Problem Suspending on Debian Etch

[David Zeuthen]

On Wed, 2006-09-27 at 20:49 +0200, Tim Dijkstra wrote:
> uswsusp will certainly not start stopping services, it does however
> do some things you also seem to be doing, like switching VTs (pm-utils
> does that rather hackishly, IMHO) and fixing the state of the graphics
> hardware. 
> But it can also do things pm-utils will never be able to
> do, like encryption and compression of the image and showing a splash
> screen during suspend and resume.

Wanted to add that nothing prevents pm-utils from using uswsusp if that
is the way forward. And it looks like it is.

I think there is some confusion here. 

pm-utils is and should just be a wrapper for the end user and ideally
tools, such as uswsusp, just integrates into that. Ie. if uswsusp is
available I'll expect the pm-utils developers to use that in the
pm-hibernate code path, if it's not we'll use the old mechanism. And
that's fine.

Of course that requires developers of such technology as uswsusp to
acknowledge that's it's useful to have a thing like pm-utils in the
first place. Because they might have to change their software a tiny bit
so everything fits. 

This is nothing new. Sometimes exercises like these are hard because
core utilities / libraries have a tendency to grow features best placed
higher in the stack. 

For example, libmusicbrainz, a library for extracting CD audio got a
nice little device probing library in case you don't know what cdrom
device to use. Things like libparted will happily probe all your disks
even though you didn't ask it too. 

Things like these are totally unnecessary on a modern desktop using HAL
that is driven by asynchronous notifications and services to find the
device reference. 

Of course, there's the embedded angle: that HAL is too heavy to use and,
sure, in good architecture dictates that core utils / libraries should
never depend on HAL. I've never rejected patches to fix the problems we
acknowledge we have in HAL, but then again I've not received many
patches like this yet. I fully understand why HAL isn't yet used in many
embedded projects. 

Of course it is unfair to say each and every project cannot grow the
features they want. I guess all I'm asking people to keep in mind the
somewhat complex stack of software that runs on top.

One such architecture is the one we're trying to push with HAL. Provide
a simple and powerful policy-free interface to users via D-Bus. And,
with PolicyKit, provide a central location to specify what users/callers
are allowed to do privileged operations.

And, please don't take this as a rant, I think we're doing pretty good
with HAL and by and large most, if not all, people / projects that care
about open source and "doing things upstream" buy into this
architecture. 

I guess I'm just trying to justify that we're *moving* system power
management abstraction from being in HAL to living in a project lower in
the stack, namely pm-utils. Because that's all there is to it, we
already have a huge switch for selecting the tool, it looks like this

 http://gitweb.freedesktop.org/?p=hal.git;a=blob;h=59cde73a5857651d77340bb0b7fdc1145e6dd1f5;hb=99f0ef983dc8724680c3892d44ec9c20df0eae1f;f=tools/linux/hal-system-power-suspend-linux

and it is truly horrible. And with pm-utils we can take the next step to
make this work a lot better, ie. define an interface whereby users / 3rd
party projects can drop files and thereby participate in system power
management work flow.

Btw, a nice side-effect is that contributors like Richard, a talented
hacker who truly cares about making power management "Just Work", gets
to maintain these bits with other like-minded individuals and who don't
have to wrestle with me to ACK patches he understands better than me
anyway.

Hope this clarifies.

     David