lkml.org 
[lkml]   [2010]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Attempted summary of suspend-blockers LKML thread, take three
    On Sat, 14 Aug 2010 09:50:00 +0200
    Pavel Machek <pavel@ucw.cz> wrote:

    > On Thu 2010-08-12 08:52:49, Ted Ts'o wrote:
    > > On Thu, Aug 12, 2010 at 03:28:01PM +0300, Felipe Contreras wrote:
    > > >
    > > > The question is why are we adding a user-space API that:
    > > > 1) no user-space beside Android has expresses interest in implementing
    > > > 2) is dubious whether the benefits are worth the pain for non-Android
    > > > user-space
    > > > 3) will become less and less attractive as dynamic PM gets closer to
    > > > the sweet-spot, and then surpass it
    > > > 4) Android can keep in a separate tree until it's clear in the linux
    > > > community that it's useful (if it ever happens)
    > >
    > > So, Felipe,
    > >
    > > Do you believe you speak for all of LKML?
    > >
    > > Are you willing to tell ZDNet and the Slashdot fanboys that it's OK
    > > for Suspend blockers to live in a separate tree, and it's not a case
    > > of OMG! Google is forking the kernel?
    > >
    > > If you could speak out a passionately on those forums as you have
    > > here, that would be great.
    >
    > Ted, what is going on here? Are you suggesting people disagreeing with
    > Google patches suddenly have to do advocacy for Google?
    >
    > And yes, for the record Felipe speaks for me pretty well.
    >
    > Normal path of merging stuff to the kernel is
    >
    > "Google develops it, then modifies it to address the review comments,
    > then it is merged, then it is deployed".

    Pavel, you should know better than this. You've been working on Linux
    long enough to know that development doesn't happen this way.

    It's far more common (and prudent, business-wise) for companies to
    develop changes against upstream Linux, ship them, and then try to get
    them or something like them integrated upstream. This often works
    fine, but big problems arise when either the company in question
    doesn't bother to ever push upstream (Linux loses out on support for a
    given feature or hardware) or ships changes that have very little
    chance of getting upstream (we end up with a fork).

    > Unfortunately what Google did here is:
    >
    > "Google develops it behind the closed door, then deploys it. When
    > asked for changes, Google expects someone else to create system
    > compatible with their existing solution, or else their patches being
    > merged."

    Although it would have been nice for Google to work more directly with
    upstream on their suspend blockers for Android, I don't think they
    could have made their product development cycle a slave to the politics
    of upstream development.

    Fortunately in this case the problem doesn't seem to be fatal. We've
    already established that the userland API portion of suspend blockers
    could be implemented in userspace with a bit more work, given that the
    kernel problems with suspend/resume and events are addressed.
    Hopefully Google is already developing a prototype userspace
    implementation to make sure it's workable; being able to build stock
    upstream kernels for my Droid and its Android userspace sure would be
    nice.

    --
    Jesse Barnes, Intel Open Source Technology Center


    \
     
     \ /
      Last update: 2010-08-16 17:19    [W:0.027 / U:0.392 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site