Re: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[tytso@mit.edu]

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