RE: Hotplug events for system suspend/resume

[Grover, Andrew]

> > > In my mind, this approach is simpler and makes more 
> sense: userspace
> > > should worry about userspace actions related to 
> suspending before calling
> > > kernelspace. Kernel space should then only worry about saving and
> > > restoring driver states and should be transparent to user 
> space. ...
> >
> > Agreed, with the minor reservations listed in a previous 
> email (suspend
> > initiated by drivers must coordinate ad-hoc with userspace, etc.).
> 
> You're thinking ACPI drivers initiating a suspend? They would 
> do it through 
> acpid, wouldn't they? At least that's the glue I use to get 
> my sleep button 
> to initiate a suspend. I would assume thermal events 
> would/should work the 
> same.

Yeah. There definitely is a need for userspace apps to be power-aware,
and have the ability to prevent suspend, but I think this should all be
done via the daemon (talking to apps via D-BUS?) and then the daemon
pulls the trigger if all power-aware apps in userspace agree it's OK. I
don't think ACPI kernel code should do anything without being told to.

The kernel sleep interface should only ever be used by the daemon. If
the user decides to use it from the cmdline then things aren't going to
work right.

My 2c,

-- Andy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/