On Sat, Apr 2, 2011 at 6:05 AM, Nicolas Pitre <nicolas.pi...@linaro.org> wrote:
> On Sat, 2 Apr 2011, Eric Miao wrote:
>
>> Yeah, staging is more close to what I meant, a 'fork' is not appropriate
>> here,
>> as getting the support into mainline will always be our goal. Yet there seems
>> to be necessary to have such a temporary place for those patches to live
>> before the mainline is in a good enough shape.
>
> No, that won't solve the problem. Patches will simply be pushed to that
> temporary place and rot there while their authors have moved on to the
> next SOC revision to enable.
>
> The problem is more fundamental due to the lack of better common
> infrastructure. We must come to a point where SOC code is obvious to
> write and right from the start. That's the only solution that scales.
>
I understand it could be even worse to have a temporary place. Yet there
is indeed a timeline gap before a generic enough infrastructure could be
implemented, and please Linus and everyone. I noted some of my ideas in
my mind last night below:
The major problem I see now is the ever increasing support for more ARM
SoC and more platforms, yet the mainline kernel so far is not in a good
shape for this scalability, not at least until the below features are
completed:
* Device tree for hardware abstraction
* Single kernel binary for most SoCs/boards
* And very hardware specific code moved out to a controllable place,
i.e. something like BIOS
So that the kernel can be generic enough. There is a time gap before
all these could be done. Thus, I'm thinking of a staging kernel tree
that:
1. Merges support for more ARM SoCs and platforms
2. Code for different SoCs and boards do not conflict and impact each
other, they live in a single branch
3. Will have a certain level of code quality, at least conforming to
mainline kernel code quality, however, upstreamable, upstreamed or
Acked-by mainline maintainers might be too strict here
e.g. Most of Freescale's BSP code is quite in a good shape already,
but won't probably make upstream maintainer happy in every place.
Yet I believe it deserves a place somewhere, not only on freescale's
extranet.
4. This kernel tree should be as much full feature as possible, unless
some driver code quality doesn't conform
5. A usable Ubuntu kernel package, an Android kernel image or a kernel
image for the LEBs that we will support could be automatically generated
from this tree, daily build and automation test would make every player
here happy
6. The tree will be sync'ed with mainline kernel constantly, I believe
what Nico is doing is already very perfectly, that we will have:
linux-linaro-2.6.38
linux-linaro-2.6.39
...
Our members are always busy working on kernel upgrade by their own,
and each upgrade they chose a kernel version based on customer's or
distro kernel's requirement. And they would normally be facing with
a big kernel version delta, and make their upgrade a great pain.
If there is already a Linaro kernel that's very usable and we help
sync with every mainline kernel release, this will definitely make
them happy.
Keeping track to every mainline kernel release would also make the
whole upgrade easier, because the delta would be much smaller. But
that of course Linaro will have to do more work, which I think could
be part of the landing team job. Even if we do little or none here,
the upgrade itself, and the daily build and automation test would
provide a great feedback to our members.
7. Due to a certain level of code requirement here, it could be the
case that SoC member still need put something on top, e.g. some
dirty patches which are necessary but could make other SoCs unusable,
and they still need their own BSP kernel. However, in this case, they
are losing nothing, because the only difference for them in this case
is to base on a Linaro kernel or a mainline kernel.
8. For our SoC member's customers, they can either get a kernel from
our members, or from Linaro. And for those very small customers that
our members have no resource to support, they don't normally care if
a kernel is coming from mainline or from Linaro, as long as it's
usable.
9. And again, upstreaming effort to mainline remains unchanged, and
this tree could serve as a great starting point.
But this would definitely increase the maintainance effort. (I'm looking
at Nico :-)
So I think the Landing team could definitely help to get in our member's
kernel support in there, as this increases our member's value.
- eric
>
> Nicolas
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
