Re: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, Jun 02, 2010 at 11:43:06PM -0700, Brian Swetland wrote: I guess it becomes an question of economics for you then. Does the cost of whatever user-space changes are required exceed the value of using an upstream kernel? Both the cost and the value would be very hard to estimate in advance. I don't envy you the decision... Well, at this point we've invested more engineering hours in the various rewrites of this (single) patchset and discussion around it than we have spent on rebasing our trees on roughly every other mainline release since 2.6.16 or so, across five years of Android development. We think there's some good value to be had (all the usual reasons) by heading upstream, so we're still discussing these patches and exploring alternatives, but yes, from one way of looking at it, it'd certainly be cheaper to just keep maintaining our own trees. And let's be blunt. If in the future the Android team (which I'm not a member of) decides that they have invested more engineering time than they can justify from a business perspective, the next time someone starts whining on a blog, or on Slashdot, or at a conference, about how OMG! Google is forking the kernel!!!, or Google is making the lives of device driver writers for the embedded world difficult, it will now be possible from a political point of view to point and the hundreds, if not thousands, of e-mail messages of LKML developers wanting to redesign this effort and saying Nyet! Nyet! Nyet! to the original patchset, to point out that Google has a made an effort, and gone far beyond what is required by the GPL. Not only has the source code been made available, but hundreds of engineering hours have been made trying to accomodate the demands of LKML --- and LKML has said no to suspend blockers/wakelocks. Realistically, a company makes decisions about whether to pursue engineering efforts based on business plans, and this is true whether the company is Red Hat, or Novell, or IBM, or Google. One of the cost/benefits can be things that aren't easily measured such as public relations. But past a certain point, it may be that the right answer is to make a single public appeal to Linus, and if he says no, or if he ignores the pull request, then the company at hand can say, We've done the best that we could, but the Linux developer community, and Linus specifically, has refused our patch. And yes, it's all about PR, but let's not kid ourselves --- the GPL and bad PR can't be used as blackmail to force a company to invest arbitrarily unlimited amounts of engineering effort just to satisfy the mandarins of the LKML and/or Linus. And if people want to call this a fork, Linus has in the past said that sometimes forks are healthy, and necessary, and we can see how things play out in the marketplace. Disclosure: I work at Google, but I'm not at all involved in the Android development team, and it's not at all my call when Brian and his team should make a decision that they've invested more time/energy than can be justified to their management --- heck, they even roll up to an completely different VP than I do. :-) - Ted -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Fri, May 28, 2010 at 04:32:15PM +0300, Igor Stoppa wrote: What I consider plain wrong i to claim that since there are this many units out, some code should be merged. A company needs to cut corners sometimes when making a product but this should not affect upstream code. Linus will disagree with you there. Linus *has* merged code on the basis that it is shipping in distributions, regardless of the fact that some developers objected to it. Sometimes perfect should not be the enemy of good enough shipping code. For example, I used to point out that we shipped PCMCIA code in mainline that had a 10% chance of crashing the system if you ejected the card. NetBSD was proud to say that their code was so iron-clad and well designed that it always did the right thing, even if you ejected while it was busily passing network traffic. Unfortunately, NetBSD had working PCMCIA support 3 years later than Linux. So it used to be that we were the technical pragmatists (and Linus fortunately, still very much is the pragmatists, while others were the hard-line perfectionists. It seems to me we've started getting some of the NetBSD attitude infecting LKML, and IMHO, that's unfortunate. We've rewritten our networking stack, 3 or 4 times, depending on how you count. And sometimes shipping in products counts for a lot. It doesn't count for everything, and it isn't a get-out-of-jail card, for sure. But if it's a hard problem, and we have something that's good enough, maybe the right call is to merge it now, and we'll rework things to make something better and more general later. Ultimately that's a call only Linus can make. If everyone agrees we're making progress, and we can let this 100+ mail thread keep going. But if anyone feels that we are spinning endlessly without making forward progress (which is after all the same criteria the OOM killer uses, no? :-), people should remember that sometimes Linus *has* ended arguments that have gone on too long by making a merge or kill decision. - Ted -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 02:25:56PM -0700, Tony Lindgren wrote: I agree and I don't understand the problem that people have with the opportunistic suspend feature. It seems to be picking quite a few comments for one. It's picking up a lot of comments because *someone* seems to be trying to use a last post wins style of argumentation. One of the things that is hard for people who aren't regular denizens of LKML is to understand whose comments can be ignored. Seriously, you are posting a lot, but it's not clear you're making any clear sense... - Ted -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
