Date:	Fri, 28 May 2010 00:31:14 -0400
From:	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 Thu, May 27, 2010 at 11:55:46PM +0100, Alan Cox wrote:
> 
> This started because the Android people came to a meeting that was put
> together of various folks to try and sort of the big blockage in getting
> Android and Linux kernels back towards merging.
> 
> I am interested right now in finding a general solution to the Android
> case and the fact it looks very similar to the VM, hard RT, gamer and
> other related problems although we seem to have diverged from that logic.

Keep in mind, though, that a solution which is acceptable for Android
has to include making sure that crappy applications don't cause the
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.

Maybe it would be acceptable if there were an easy way THAT A USER AND
NOT A DEVELOPER COULD USE ON A SMART PHONE to find the bad
application, but realistically, it's much better if the solution can
work well even in the face of crappy application.  Having interacted
with application programmers, I can assure you there are a lot of
crappy application programmers out there, and they vastly outnumber us
kernel developers.  (See as exhibit A all of the application programs
who refuse to use fsync, even though it's going to wipe them out on
all new modern file systems, including btrfs.)

We need to agree on the requirements up front, because otherwise this
is going to be a waste of everyone's time.

And if we can't get agreement on requirements, I'd suggest appealing
this whole thing to Linus.  Either he'll agree to the requirements
and/or the existing implementation, in which case we can move on with
our lives, or he'll say no, in which case it will be blately obvious
that it was Linux developer community who rejected the Android
approach, despite a fairly large amount of effort trying to get
something that satisfies *all* of the various LKML developers who have
commented on this patch, and we can continue with Android having
kernel which is different from mainline --- just as many other
embedded companies have patches which are utterly required by their
products, but which have been judged Too Ugly To Live In Mainline ---
and we can also move on and get on with our lives.

						- Ted

P.S.  Keep in mind how this looks from an outsider's perspective; an
embedded manufacturer spends a fairly large amount of time answering
one set of review comments, and a few weeks later, more people pop up,
and make a much deeper set of complaints, and request that the current
implementation be completely thrown out and that someone new be
designed from scratch --- and the new design isn't even going to meet
all of the requirements that the embedded manufacturer thought were
necessary.  Is it any wonder a number of embedded developers have
decided it's Just Too Hard to Work With the LKML?
--
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