Status of the linaro-2.6.38 kernel
john.rigby at linaro.org
Mon Mar 28 14:26:07 UTC 2011
The rebuilt branch is fine for me. My tree creation methodology is
patterned after the Ubuntu kernel which means I rebase to new
upstreams each release so I don't mind if my upstreams do as well.
On Sun, Mar 27, 2011 at 10:06 PM, Nicolas Pitre
<nicolas.pitre at linaro.org> 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
> 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://git.linaro.org/kernel/linux-linaro-2.6.38.git (the "rebuilt" branch)
> linaro-dev mailing list
> linaro-dev at lists.linaro.org
More information about the linaro-dev