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]

Message-ID: <20141030174135.GA13814@amd>
Date:	Thu, 30 Oct 2014 18:41:35 +0100
From:	Pavel Machek <pavel@....cz>
To:	Bastien Nocera <hadess@...ess.net>
Cc:	Theodore Ts'o <tytso@....edu>,
	Andy Lutomirski <luto@...capital.net>,
	John Stultz <john.stultz@...aro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: A desktop environment[1] kernel wishlist

On Thu 2014-10-30 16:15:15, Bastien Nocera wrote:
> On Thu, 2014-10-30 at 11:05 -0400, Theodore Ts'o wrote:
> > On Thu, Oct 30, 2014 at 03:45:02PM +0100, Bastien Nocera wrote:
> > > > Actually Maemo people (on Nokia N900 and friends) got it right: unlike
> > > > android devices, it does not suspend to RAM at any point, and still
> > > > has reasonable battery life.
> > > 
> > > Android devices don't suspend to RAM. Neither do Tizen devices AFAIK.
> > 
> > Actually, Android devices have historically always suspended the CPU
> > whenever there wasn't a wakelock keeping the device to suspend.  You
> > might not consider this "suspend to RAM" but in fact it uses the
> > identical kernel and hardware facilities as the legacy "suspend to
> > RAM" mechanism.
> 
> I wouldn't consider this "suspend to RAM", but that's because I expect
> the firmware to implement most of that. Anyway, that's splitting
> hair.

Could you rephrase that?

Anyway, this is "echo mem > /sys/power/state" or
suspend-to-RAM. Android does the same, with more tricky wakeup logic. 

> > > I don't think anyone was discussing cell phones in particular in this
> > > thread, and knowing when user-space got woken up because of the baseband
> > > processor having information for us would still be useful.
> > 
> > It matters because for laptops, what's important is whether the lid is
> > closed or not.  Whether and how the laptop was "woken" is really
> > beside the point, as others have argued.  Your counter argument is
> > that tablets don't have lids.  But tablets are going to be using
> > schemes similar to Android, Tizen, and Maemo, and they are *not* going
> > to be using the legacy suspend-to-RAM model, because it's not
> > sufficiently good at power saving.
> 
> There are plenty of tablets around that aren't Android devices. There
> are plenty of laptops that can be switched to a tablet mode for which
> this wouldn't apply either.

Yes, still the right question is "was the power button pressed while
userland was suspended" not "was the system woken by power
button"... and yes, I guess kernel should add the "power button" event
to the input queue, even if that press was used to wake up the system.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/