All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yan Pashkovsky <yanpaso@gmail.com>
To: linux-pm@vger.kernel.org
Subject: Re: API for querying the resume cause
Date: Fri, 21 Aug 2015 00:44:44 +0300	[thread overview]
Message-ID: <55D64A4C.5000604@gmail.com> (raw)
In-Reply-To: <55D5BE6B.5070805@gmail.com>

Hi, I have subscribed to linux-pm@lists.linux-foundation.org and 
Majordomo@vger.kernel.org (linux-pm). I've written you earlier, hope you 
received my message. I haven't received any replies, so I send this 
message again, cause I think my message was declined.

20.08.2015 14:47, Yan wrote you:
 > Dear developers,
 >
 > My name is Yan and I was redirected here from kernel bugzilla
 > (bugzilla.kernel.org/show_bug.cgi?id=102991). I would like to discuss
 > API for supporting delayed hibernation.
 >
 > Original post:
 >
 >     Please add API for querying the resume cause
 >     The purpose of this API - is support of delayed hibernation (feature
 >     that works for a long time in Windows). A laptop first Suspend to
 >     RAM, then after a time save state to disk and power off completely.
 >     But system must know the reason of waking up (was it user or turning
 >     into hibernation). RTC wakeup event isn't reliable.
 >     SystemD needs such API, see more at
 >     github.com/systemd/systemd/issues/926
 >
 >
 > I was discussing it earlier with Lennart Poettering, he said he can't
 > rely on rtc timer, he needs some API.
 > Lennart(github.com/systemd/systemd/issues/926):
 >
 >     On Linux we have no API for querying the resume cause. Patching
 >     around this sounds like a gigantic hack... Especially as RTC-based
 >     wakeups are not really reliable on many systems... On such systems
 >     where the RTC wakeup is missed and the user resumes the machine
 >     manually later on the system will immediately go to hiberantion,
 >     which is clearly not a good idea.
 >
 >     Sorry, but I am really not convinced this could be any more than a
 >     gigantic hack.
 >
 >     Please before looking into something like this, let's at least get a
 >     proper API into the kernel that reports the precise wakeup reason to
 >     userspace. If we have that, then we can consider hooking this up
 >     from userspace. Will close this for now, as I don't think we should
 >     hack something up like this without proper kernel support for such a
 >     logic.
 >
 >
 > PS I use mailing list system for the first time. Am I to subscribe to it
 > somewhere? Will feedback be delivered to my email address after sending
 > this email, without any actions?
 >
 > King regards,
 > Yan

  reply	other threads:[~2015-08-20 21:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-20 11:47 API for querying the resume cause Yan Pashkovsky
2015-08-20 21:44 ` Yan Pashkovsky [this message]
2015-08-21  2:07 ` Krzysztof Kozlowski
2015-08-21  3:17   ` Yu Chen
     [not found]     ` <9D8C9A00-9AA7-4BA1-9953-3DB1A88468D5@gmail.com>
2015-08-21 21:09       ` Yan Pashkovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55D64A4C.5000604@gmail.com \
    --to=yanpaso@gmail.com \
    --cc=linux-pm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.