|To:||Alan Cox <alan-AT-lxorguk.ukuu.org.uk>|
|Subject:||Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)|
|Date:||Fri, 28 May 2010 00:31:14 -0400|
|Cc:||Matthew Garrett <mjg59-AT-srcf.ucam.org>, Alan Stern <stern-AT-rowland.harvard.edu>, Thomas Gleixner <tglx-AT-linutronix.de>, Peter Zijlstra <peterz-AT-infradead.org>, LKML <linux-kernel-AT-vger.kernel.org>, Florian Mickler <florian-AT-mickler.org>, felipe.balbi-AT-nokia.com, Linux OMAP Mailing List <linux-omap-AT-vger.kernel.org>, Linux PM <linux-pm-AT-lists.linux-foundation.org>|
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-omap" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds