<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Please add the ability to go into standby mode to systemd-sleep." href="https://bugs.freedesktop.org/show_bug.cgi?id=57793#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Please add the ability to go into standby mode to systemd-sleep." href="https://bugs.freedesktop.org/show_bug.cgi?id=57793">bug 57793</a> from <a class="email" href="mailto:lennart@poettering.net" title="Lennart Poettering <lennart@poettering.net>"> Lennart Poettering</a> <pre>I think we should avoid introducing high-level verbs for all possible kernel power management states. Instead it might be useful to allow changing what the existing verbs mean. Already now we don't expose the kernel's vocabulary 1:1 in systemd. We use "hibernate" for what the kernel calls "suspend" and "disk" at some places, and "suspend" for what the kernel calls "sleep" and "mem". I'd thus suggest we simply define some rough semantics for the existing three verbs, but leave it to the specific system to actually bind them to whatever the underlying hardware might support. Maybe some definitions like the following: suspend = a low-power state where execution of the OS is paused, and complete power loss might result in lost data, and which is fast to enter and exit hibernate = a low-power state where execution of the OS is paused, and complete power loss does not result in lost data, and which might be slow to enter and exit hybrid-sleep = a low-power state where execution of the OS is paused, which might be slow to enter, and on complete power loss does not result in lost data but might be slower to exit in that case. These rough definitions would then allow implementations to implement the verbs with different logic behind, possibly even implementing some of them with the exact same result (for example, hybrid sleep is a "superset" of hibernate, and hence any implementation for hybrid-sleep might be suitable for hibernate too.) Now, coming back to the actual request this bug is about: with this scheme in place we could then enable users, admins or system builders to override the default logic systemd uses, for example to change "suspend" from meaning "mem" to "standby", and this would be perfectly within the definitions above. The question would then only be where to configure what the "systemd-sleep" binary actually writes into /sys/power/kernel. Instead of introducing a new configuration file a simple approach could be to add support for a new command line argument to "systemd-sleep" to cover the "standby" case, and then ask the admin to copy /usr/lib/systemd/system/systemd-sleep.service to /etc/systemd/system/systemd-sleep.service and edit it there to append the argument. This solution makes the mapping of the high-level verbs to the low-level implementations a configuration option. One couldn't enter the low-level operations without changing configuration. I personally don't see that as much of a problem though. If we go this way we probably should set up a wiki page describing what the user/admin/system integration needs to do to change the meanings of suspend/hibernate/hybrid-sleep.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>