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: <201006052104.05324.rjw@sisk.pl>
Date:	Sat, 5 Jun 2010 21:04:05 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Felipe Contreras <felipe.contreras@...il.com>
Cc:	Florian Mickler <florian@...kler.org>,
	Peter Zijlstra <peterz@...radead.org>,
	James Bottomley <James.Bottomley@...e.de>,
	Arve Hjønnevåg <arve@...roid.com>,
	tytso@....edu, LKML <linux-kernel@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	felipe.balbi@...ia.com, Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Saturday 05 June 2010, Felipe Contreras wrote:
> On Mon, May 31, 2010 at 11:47 PM, Florian Mickler <florian@...kler.org> wrote:
> > On Mon, 31 May 2010 22:12:19 +0200
> > Florian Mickler <florian@...kler.org> wrote:
> >> If I have a simple shell script then I don't wanna jump through
> >> hoops just to please your fragile kernel.
> >
> > Also why should that code on one device kill my uptime and on the
> > other machine (my wall-plugged desktop) work just well? That doesn't
> > sound right.
> 
> Sounds perfectly right to me; one code runs perfectly fine on one
> machine, and on the other doesn't even compile. Well, sure, it wasn't
> written with that use-case in mind.
> 
> > Clearly opportunistic suspend is a workaround for battery-driven devices
> > and no general solution. But it is not specific to android. At least
> > not inherently. It could be useful for any embedded or mobile device
> > where you can clearly distinguish important functions from convenience
> > functions.
> 
> Yes, it could, but why go for the hacky solution when we know how to
> achieve the ideal one?
> 
> > I really can't understand the whole _fundamental_ opposition to this
> > design choice.
> 
> Nobody is using it, except Android. Nobody will use it, except Android.

That's like saying "Android is not a legitimate user of the kernel".  Is that
you wanted to say?

> I have seen recent proposals that don't require changing the whole
> user-space. That might actually be used by other players.

Sure, an approach benefitting more platforms than just Android would be better,
but saying that the kernel shouldn't address the Android's specific needs as a
rule if no one else has those needs too is quite too far reaching to me.

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