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:	Wed, 28 Sep 2011 10:19:33 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	John Stultz <john.stultz@...aro.org>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, arve@...roid.com,
	markgross@...gnar.org, Alan Stern <stern@...land.harvard.edu>,
	amit.kucheria@...aro.org, farrowg@...ibm.com,
	"Dmitry Fink (Palm GBU)" <Dmitry.Fink@...m.com>,
	linux-pm@...ts.linux-foundation.org, khilman@...com,
	Magnus Damm <damm@...nsource.se>, mjg@...hat.com,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/6] [RFC] Proposal for optimistic suspend idea.

On Tue, 2011-09-27 at 15:56 -0700, John Stultz wrote:
> > For instance anybody trying to draw to an X surface after they've been
> > told the screen is off should get kicked. (And before people go whinge
> > about d-bus having to wake all tasks to get the msgs across, which
> > wastes power; if you fix the runtime up far enough the attempt of
> > drawing could return this information.)
> > 
> > I'm not quite sure how timer-slack comes into this, because every app
> > receiving random wakeups (no matter what slack) after its been told it
> > should quiesce is a fail, with the exception of the wakeup for telling
> > it its good to go again (but that comes _after_ the system policy
> > change, so its fine).
> 
> So you're suggesting we rewrite everything in the debian package
> archives to use DBUS and abide by some sort of userland power policy?
> 
> I'll admit its a terrible straw-man, but this starts to sound like: "We
> don't need protected memory! Just rewrite all the apps so they don't
> accidentally overwrite kernel structures!"
> 
> Don't get me wrong, I do think that there are power-optimizations to be
> had using more "runtime" regulated behavior. You're right, when the
> screen is powered off, the clock applet shouldn't be trying to make X
> calls to update itself every minute.
> 
> But I think once you get away from some theoretical system, containing
> only properly behaving apps, having some tools in the kernel to enforce
> a certain type of behavior (and having the kernel's ability to handle
> more complex cases like importance inheritance) might be helpful. 

So you want to add something that sends a SIGBUS or similar to an
application if it gets a wakeup when its not supposed to? That's what
happens with memory protection, you get killed.

And yes, when Arjan did his powertop thing people did go fix up
everything that made the top.

It really isn't that hard to fix most of these apps. But the problem
with Android is that the battery usage thing it has is utterly useless.
It mostly just tells you wireless or whatnot is sucking power, not what
app is causing that. (And of course the fact that its all fucking Java
crap, which I'll refuse to touch anyway).

This results in people (me) uninstalling everything they installed since
last it worked well and then cursing this crappy shit for wasting their
time.

I really think Android is a pile of privacy violating shit, I can't say
I actually enjoy using the phone. I'm at a point where I can call with
it (without it telling google whoem all I know and where I'm at) and
browse the interwebs and have decided to screw apps, they don't work
anyway.

The only reason I'm not back to the N900 is because the Android thing is
a lot faster at rendering web (better cpu etc..).


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ