<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><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 <span class="vcard"><a class="email" href="mailto:lennart@poettering.net" title="Lennart Poettering <lennart@poettering.net>"> <span class="fn">Lennart Poettering</span></a>
</span></b>
        <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>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the QA Contact for the bug.</li>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>