Status of the linaro-2.6.38 kernel

Paul E. McKenney paulmck at
Mon Mar 28 15:17:47 UTC 2011

I favor sticking close to mainline unless it irreparably breaks something.

							Thanx, Paul

On Mon, Mar 28, 2011 at 12:06:31AM -0400, Nicolas Pitre wrote:
> Hello everyone,
> As I've been working on the integration of the latest developments and 
> fixes from upstream into the linaro-2.6.38 kernel lately, it became 
> quickly evident that major merge conflicts were to be expected.  The 
> problem stems from the fact that we opened the 2.6.38 branch early i.e. 
> around the 2.6.38-rc5 kernel.  Many patches that were merged into the 
> Linaro kernel have been subsequently modified by their respective 
> maintainers until they were merged upstream, meaning that what we have 
> now in mainline is different from what the Linaro kernel tree has.  This 
> creates several issues:
>  - It is hard to verify that what is in the Linaro tree is actually the 
>    latest and the best version of a patch.
>  - Merging additional fixes from upstream often ends up in merge 
>    conflicts requiring manual resolution, sometimes non-trivial ones, 
>    which is in itself a bug hazard.
>  - People wanting to contribute patches to the Linaro kernel potentially 
>    have to create a different patch than what they would submit 
>    upstream.
> Given those issues, I decided to rebuild the linaro-2.6.38 branch from 
> scratch to see where that would bring me.  And as could be expected, the 
> result looks nicer and it is much easier to work with than the current 
> tree.  For example, this allowed me to merge the latest OMAP support 
> from mainline as is, including the latest fixes, without any need for 
> backport work nor major conflict resolution.  Another advantage is that 
> the commit SHA1 references are now identical in most cases to what can 
> be found into mainline.
> So... my question is: should we switch to this rebuilt tree or not?  
> There are drawbacks with such a move of course:
>  - All the testing done so far would be void.  This is however not as 
>    bad as this may look as the rebuilt kernel contains fixes for existing
>    bugs in the current tree, and the rebuilt kernel is using patches 
>    that have and still are being tested by a wider community.
>  - I didn't forward port a couple series of patches that are available 
>    in the current Linaro tree and not in mainline yet, including:
>     * DT support (Grant Likely)
>     * DVFS and PM for OMAP (Vishwanath Sripathy, Vishwanath BS)
>     * Some ux500 fixups (Linus Walleij)
>     * clock debug information (Yong Shen)
>     * Samsung CPUIDLE (Amit Kachhap)
>    So I would prefer if the people responsible for those patches did 
>    resubmit their patches once they apply to the new tree (that should 
>    be even easier now to apply patches that were meant for mainline).
>  - The history of the rebuilt tree is obviously different from the 
>    current tree's.  This means special care when updating to the new 
>    tree with Git.
> But overall I think there are more advantages than disadvantages for 
> such a move.  What other people think?
> The current rebuilt tree can be seen at:
> or obtained from:
> git:// (the "rebuilt" branch)
> Nicolas
> _______________________________________________
> linaro-kernel mailing list
> linaro-kernel at

More information about the linaro-dev mailing list