On Sat, Apr 2, 2011 at 6:05 AM, Nicolas Pitre nicolas.pitre@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