Re: A desktop environment[1] kernel wishlist

[John Stultz]

On Tue, Oct 21, 2014 at 10:14 AM, Bastien Nocera <hadess@xxxxxxxxxx> wrote:
> Hey,
>
> On Tue, 2014-10-21 at 10:04 -0700, John Stultz wrote:
>> On Tue, Oct 21, 2014 at 1:49 AM, Bastien Nocera <hadess@xxxxxxxxxx> wrote:
>> > Hey,
>> >
>> > GNOME has had discussions with kernel developers in the past, and,
>> > fortunately, in some cases we were able to make headway.
>> >
>> > There are however a number of items that we still don't have solutions
>> > for, items that kernel developers might not realise we'd like to rely
>> > on, or don't know that we'd make use of if merged.
>> >
>> > I've posted this list at:
>> > https://wiki.gnome.org/BastienNocera/KernelWishlist
>> >
>> > Let me know on-list or off-list if you have any comments about those, so
>> > I can update the list.
>>
>> As for: 'Export of "wake reason" when the system wakes up (rtc alarm,
>> lid open, etc.) and wakealarm (/sys/class/rtc/foo/wakealarm)
>> documentation'
>>
>> Can you expand more on the rational for the need here? Is this for UI
>> for power debugging, or something else?
>
> No, it would be used for automating backups, or implementing
> suspend->hibernation transitions. For example, right before the machine
> suspends, I would schedule it to wake up in a hour. If I get woken up by
> the rtc alarm (and not by the user through a lid open), I might:
> - check that I'm plugged into the AC, it's night, and in the vicinity of
> the server that handles my backups and so backup the system.
> - check whether the battery is low, and hibernate the machine (if it
> supports it, obviously).
>
> We cannot do that if we can't make out whether the wake-up came from a
> user action, or the alarm we set.

I suspect wakeup type reporting is maybe not the best way to go about
this, since there may be a number of causes for wakeups and they can
arrive closely together in different orders, which can result in
races.

For instance, if the machine suspends, and sets an alarm to be woken
up at midnight to do a backup, if the user resumes their laptop at
11:59:59, should the backup still proceed at midnight?  What happens
if the user starts to use their machine at 12:00:01?  What about if
the user walked away from their machine at 11:55:01, and the system
would suspend at 12:00:01, should the backup commence at 12:00:00?

Thus you probably want to have a "user present" status, then use the
timerfd() ALARM clockids to set any wakeups you'd like, and when they
trigger (if the system was suspended or not), decide to do your backup
based the conditionals you had above, using the user-present status in
a similar way to how you use AC status.

I'd suggest looking into some of the details on how Android does its
wakelock logic, as well as the timerfd ALARM clockids, since I think
this would provide what you need.

My bigger concern here with your use case though, is that you might be
able to use ALARM timers more commonly, but that for much existing
hardware, corner cases like programmatic resuming of a laptop while
its packed in a bag somewhere might have thermal risks.  For mobile
devices this is an expected design point, but for off-the-shelf
laptops with big fans and exhaust vents, I'm not sure how safe this
would be, so you may need to constrain this functionality somehow (or
look to see if a enforced low-power resume is possible).

thanks
-john
--
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/