Which kernel should outside developers use?
Christian Robottom Reis
kiko at linaro.org
Wed Apr 4 20:22:51 UTC 2012
On Wed, Apr 04, 2012 at 05:54:13PM +0100, Chris Simmonds wrote:
> >Is this a new SoC (no mainline support) or an existing SoC?
> It's a new SoC which will have its own arch/arm/mach-xxx directory
You haven't stated clearly your intention -- is it your first priority
to have support for this platform included in Linus' mainline, or are
you more interested in the bring-up for a product goal?
> >>So my questions are
> >>1. Is this a rational approach?
> >IMHO, you should be developing against mainline, say the last released
> >kernel 3.3, if tracking 3.4-rc is too much. And then ask for it to be
> >merged via the arm-soc tree if you have no other sub-arch maintainer
> >above you.
> It is not feasible to track the tip mainline release both because it
> eats up man power in the kernel team but even more so in the QA
> team. Probably looking at one kernel release per year, ideally based
> on the long term kernel, currently 3.0.
Based on your answer, I am guessing the latter option of the two I
> When it comes to mainlining, is arm-soc the best way? There is no
> route via Linaro?
That's correct -- the linux-linaro kernel is an integration tree,
intended to validate and test cutting edge work happening in both
working groups and member SoC and board bring-up. If you want to produce
something suitable for mainline, you should base on trunk and uplevel
your patches as mainline progresses.
In other words, the linux-linaro kernel isn't intended to be a base for
/SoC bringup/ efforts [*]; it's much better for you to track trunk and
bring in specific branches that you care about.
Note that I would certainly not start on 3.0, which is getting old very
quickly. If you absolutely care about starting from a "stable" base,
then I would start on the latest released kernel (currently 3.3); the
state of things in ARM are such that every release you go backwards
causes you to miss critical plumbing that we are working on.
> >If you need specific features from the Linaro tree, you should use git
> >branches to track the tree and cherry-pick the bits that you do need.
> >Can you give examples of things that you do need from the Linaro tree?
> Basically, everything in arch/arm/kernel, arch/arm/mm, etc. Right
> now the diff is mostly to do with device tree, which is interesting
> but not crucial. But the principle is that linux-linaro will have
> arm architecture support before mainline, no?
Yes, but you shouldn't base your work on linux-linaro, and instead on
the topic branches that you care about -- basing your work on a history
tree is going to lead to a path of tangled patches that will be much
harder to upstream.
A manifest of the branches being included in linux-linaro will be
available online shortly; I'm waiting for Andrey (copied here) to
[*] The complementary question is what /is/ linux-linaro for, if not to
support new SoC bringup. The answer is that it's there to allow people
to test cutting edge kernel work on Linaro member platforms -- for
instance, if you want to verify how well Device Tree support works on an
i.MX53 Quickstart, or how well the latest eMMC 4.5 storage patches work
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs
More information about the linaro-dev