[Pm-utils] Re: Better integration with power management scripts

[David Zeuthen]

On Thu, 2006-04-27 at 22:35 +0200, Stefan Seyfried wrote:
> No, i need to know if the machine actually was powered off and resumed
> before "echo disk > /sys/power/state" returned. If one driver refuses to
> suspend or there is not enough swap space, or ..., this does not have
> to be true. Again, the "battery critical suspend" case is an example:
> if suspend fails in this case, i'd like to shut down.
> This can be deduced from the return value of echo in this case (or better
> from the return code of write(2) which gives the exact error), but we need
> to propagate this to the policy-deciding program.
> But this will not be a problem - everybody will easily agree that this needs
> to be propagated :-)

What's the problem? If we just have well defined error reporting from
pm-suspend and friends like I described in my other mail (linked below)
you will be able to figure this out. 

Notably HAL today throws an exception whether Suspend() etc. failed and
I'm also proposing to extend the number of exceptions it may throw so
you can build UI gizmos to say "Unable to suspend because the Loadable
Kernel Module foobar.ko is broken". I still think that's useless though,
if the user knows what a LKM is he knows to look in the syslog.

> > No, now you're arguing "We need this feedback because we're providing 
> > the ability for people to do broken things". A better solution is "Don't 
> > provide the ability for people to do broken things". Figure out what 
> > vendors need, and then design for that - don't leave the design so open 
> > that people can ship completely crack-addled addons, because they'll do 
> > so and the world will be a worse place.
> 
> I have to disagree here. People use linux because it allows them to do small
> hacks easily for stuff they need and that none of the developers had
> anticipated. 

First, if the feature is so important it needs to go upstream. Second,
in my not so humble opinion as a free software maintainer for quite a
few projects, the defacto situation right now is that things like this
just allow lots of users to break the software in not so interesting
ways. And that takes attention away from maintainers. Everybody loses.
That's also why the Linux kernel has the tainted flags since no-one
bothers to debug problems from binary only crap. Notably kernel
developers also don't normally care about out-of-tree modules. They tell
users to get it upstream.

It's about solving the problems upstream, once and for all - not stupid
hacks and options that will make the software explode.

> Calling all this special stuff "broken" is a bit arrogant IMO :-)

Options, hooks and all that is the root of all evil [1]. But since I nor
others are not going to change your mind here I've also proposed
the /etc/pm/notifiers.d interface, see my other mail (linked below). I'm
not sure I can convince the other stake holders of pm-utils to add this
and, eh, you guys haven't replied to it at all.

[1] : http://ometer.com/free-software-ui.html ; Havoc knew this back in
2002 although the essay is mostly concerned about User Interface. It
still rings perfectly true for this case however.

> IMO we should have some places, where people can easily hook in their "broken
> things". If we can't agree on feedback being useful, we should at least try to
> agree on "custom hooks" so that users can do stuff that is useful for them.

Sure, reply to this mail

 http://lists.freedesktop.org/archives/hal/2006-April/005039.html

where I list concrete enhancements to the current pm-utils code.

> I always was surprised how creative people were when it came to (ab-)using
> the software i wrote, but i do not think this is necessarily a bad thing :-)

I believe in extensible software but I'm very reluctant to adding hooks
and extension interfaces because they are very very expensive to
maintain.

    David