[lkml]   [2010]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: suspend blockers & Android integration
    On Fri, Jun 4, 2010 at 12:57 AM, Ingo Molnar <> wrote:
    > * Brian Swetland <> wrote:
    >> We started here because it's possibly the only api level change we have --
    >> almost everything else is driver or subarch type work or controversial but
    >> entirely self-contained (like the binder, which I would be shocked to see
    >> ever hit mainline). [...]
    > So why arent those bits mainline? It's a 1000 times easier to get drivers and
    > small improvements and non-ABI changes upstream.
    > After basically two years of growing your fork (and some attempts to get your
    > drivers into drivers/staging/ - from where they have meanwhile dropped out
    > again) you re-started with the worst possible thing to merge: a big and
    > difficult kernel feature affecting many subsystems. Why?

    Because a large number of our drivers depend on it.

    > This is one of the fundamental problems here. People simply dont know you,
    > because you have not worked with us much - and hence they dont trust you
    > positively out of box - they are neutral at best.
    > And believe me, it's hard enough to get difficult features upstream if people
    > _do_ know you and when they positively _do_ trust you ... Arent you talking to
    > Andrew Morton about how to do these things properly? This is kernel
    > contribution 101 really.
    >> [...]  Assertions have been made that because the "android kernel" (not a
    >> term I like -- linux is linux, we have some assorted patches on top) [...]
    > I've been tracking android-common and android-msm for a while and i have to
    > say that it shows a very lackluster attitude towards upstream:
    >  - The latest branches i can see are v2.6.32 based today. We are in the
    >   v2.6.35 stabilization cycle and are developing v2.6.36. I.e. your upstream
    >   base is about a year too old.

    We have some branch naming confusion and work going on in
    experimental, but our active work right now is against 2.6.34 and
    2.6.35-rc. The tegra2 work has been very aggressively following
    mainline (rebasing against 2.6.34rc as they were getting underway),
    and we've been sending those patches out for review, in hopes of
    getting that tree off on a better foot.

    >  - The last commit is a couple of weeks old AFAICS.
    >  - The diffstat of android-common/android-2.6.32 is:
    >      890 files changed, 39962 insertions(+), 6286 deletions(-)
    >   Those assorted patches have spread over nearly a thousand files. FYI, by
    >   the looks of it you are facing an exponentially worsening maintenance
    >   overhead curve here.
    > Is there perhaps some other tree i should be following? I'm looking at:
    >  [remote "android-msm"]
    >         url = git://
    >         fetch = +refs/heads/*:refs/remotes/android-msm/*
    >  [remote "android-common"]
    >         url = git://
    >         fetch = +refs/heads/*:refs/remotes/android-common/*
    > Btw., the commits i've glanced at looked mostly clean and well structured, so
    > i see no fundamental reason why this couldn't be done better.

    I think the fundamental issue we keep bumping into is the turnaround
    time on patch review / inclusion (again we're trying to get things
    going much earlier on tegra2 to hopefully have less pain there). We
    aim for kernel style compliance (though we're not perfect and we make
    our share of mistakes), but previously when I tried sending mach-msm
    stuff out, it seemed infeasible to send 30-60+ patches, so we'd start
    with 5-10, feedback would trickle in over the course of a week, I'd
    respin, etc. After a couple weeks some stuff would get picked up
    toward a merge window but the rest would have to wait. And then we
    hit crunch to ship, etc, and get behind.

    Totally our fault that we're not just constantly pushing patches (and
    we're trying to get a fulltime engineer or two just to work on
    upstream related stuff), but we rapidly hit the point where what we're
    sending up is a drop in the bucket compared to the work we're doing
    and things keep diverging, etc.

    I'm told this happens to everyone, is common, etc. We're (seriously)
    a small team, trying to ship multiple products a year and keep our
    head above water here, and unfortunately that means we keep tabling
    these projects until we can find some cycles to give it another go and
    the delta grows.

    >> So, we figure, let's sort out the hard problem first and then move on with
    >> our lives.
    > Well, my suggestion would be to first build up a path towards upstream, build
    > up trust, reduce your very high cross section to mainline - and do the most
    > difficult bits last.

    Having to maintain two versions of about half our driver code because
    we depend on an ABI not in mainline is a significant factor for us --
    it's difficult to have what's going upstream lag behind our active
    work (basically we have to maintain two different trees -- one for
    mainline one for ship) already, but having these codelines also be
    different makes it worse for us.

    > Especially 'move on with our lives' suggests that you just want to get rid of
    > this ABI divergence and continue-as-usual with the pattern of non-cooperation,
    > hm?

    I'd like to make some forward progress either to get something
    wakelock-ish in and shift to whatever that api is, or to get a clear
    "no not going to happen" and deal with the fallout there.


    Sadly, for mach-msm, we're now further out due to maintainership
    shifts (Daniel stepped up to do msm stuff, is pushing up some hybrid
    of our work and Qualcomm's work that doesn't seem to really fit with
    either, and I have no idea how to sanely get our stuff to sit on top
    of that). I'd love to find some time to sit down, clean up the whole
    msm tree for 8x50/7x30 which is (largely) pretty clean, and is
    extremely stable and shippable, and try to get it into a patch series
    and headed upstream, but we're now colliding with the upstream
    mach-msm which has gone off in a different direction, etc.

    Anyway, we continue to try to figure out how to make stuff work better
    (again, trying some different approaches with tegra2), but so far the
    process of getting code upstream has been extremely time intensive and
    rather frustrating and it remains unclear who can sign off on what and
    how many hoops different people will keep asking us to jump through.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2010-06-04 10:33    [W:0.058 / U:13.988 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site