linux-kernel - Re: A desktop environment[1] kernel wishlist

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 31 Oct 2014 14:54:40 +0100
From:	Bastien Nocera <hadess@...ess.net>
To:	John Stultz <john.stultz@...aro.org>
Cc:	Zygo Blaxell <zblaxell@...ryterror.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: A desktop environment[1] kernel wishlist

On Tue, 2014-10-28 at 07:36 -0700, John Stultz wrote:
> On Tue, Oct 28, 2014 at 5:36 AM, Bastien Nocera <hadess@...ess.net> wrote:
> > Maybe the wake-up reason isn't good enough on its own, but how do I know
> > which one the possible wake-up reasons was the last one to trigger?
> 
> So I feel like I'm still missing why its so critical to know what the
> last-event was?  To me it seems a number of events have occurred, and
> they should all be processed. Since they're all asynchronous, they
> could come in any order, so it seems best handle them one by one
> rather then have any requirement on which one happened last.
> 
> What does the exact timeline of the events provide for you?

What's most important is the reason for (device) wake-up. I could see if
the event that woke up the machine was Wake-On-LAN (which would wake up
the screen), or the proximity of wireless networks (Wi-Fi card firmwares
can do that on their own) (which wouldn't wake the screen up).

The timestamp makes it possible to avoid races that were mentioned
earlier in the thread.

Knowing whether an alarm or a button woke the machine would be useful as
well (even if we would need to monitor additional resources, such as the
input devices, or accelerometers, to know what state the machine
currently is in).

As others mentioned, this is also useful as a power debugging tool. The
important part here would be that each device would report its own
wake-up reason, which the driver can know better than user-space or
other parts of the kernel. User-space would be responsible for
coalescing that information.

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