linux-kernel - Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

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: <06439EEF-9404-45DC-AB37-5CC0486CCF6C@mit.edu>
Date:	Fri, 28 May 2010 08:16:08 -0400
From:	Theodore Tso <tytso@....EDU>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>, felipe.balbi@...ia.com,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On May 28, 2010, at 5:37 AM, Alan Cox wrote:

>> Keep in mind, though, that a solution which is acceptable for Android
>> has to include making sure that crappy applications don't cause the
> 
> Ted if you are speaking for Android do you think you should post from a
> google address or with a google .sig ?

We're all engineers here.   Nobody speaks for the company as a whole without the permission of corporate PR, and that's true for Intel, IBM, and all other companies.

>> battery to get drained.  There seem to be some people who seem
>> adamently against this requirement.  From the Android folks'
>> perspective, this is part of what is required to have an open app
>> store, as opposed to one where each application has to be carefully
>> screened and approved ala the Apple iPhone App Store.
> 
> The other vendors appear to be managing nicely without magic blockers. I
> conjecture therefore there are other solutions.

I've seen very hard to debug situations  with Maemo where users are essentially asked to uninstall all their applications, and then install them back one at a time, waiting several hours between each install for a charge/discharge cycle, to figure out which application was waking up the system so !@#@! much while the screen was turned off.   And, when the periodic wakeups are faster than the refresh time of powertop, no, powertop won't help you find the crapplication.   If you think that's acceptable, fine --- we'll see who wins in the marketplace, and who gets blamed for producing a crappy platform --- the incompetent application programmer, or the platform supplier.

> If we don't have a solution it means that between us we couldn't find a
> viable solution. Maybe there isn't one, maybe we missed it. It's as much
> 'google rejects kernel approach' as 'kernel rejects google approach' and
> more importantly its actually 'we (cumulative) were not smart enough
> between us to figure it out'

Maybe.  And perhaps the right solution in that case is to merge both, as opposed to "consign one to the outer darkness".   And I think that's a decision Linus should make.

I do hope we can come up with a better solution, eventually.  But I do want to point out as a process point of view, we do have other alternates other than "spinning endlessly".

-- Ted

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