On Sat, 2 Apr 2011, Eric Miao wrote:
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.
There is also a catch. Unless you have the power of precognition, it is extremely hard to predict what is going to be common in the future and therefore might call for a generic infrastructure. And without that generic infrastructure, people will be tempted to duplicate code for their own purpose. It is therefore important to be on the lookout for such duplications when they occur and be quick to provide infrastructure to reduce them.
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
Sure.
- Single kernel binary for most SoCs/boards
Well... While this is a worthwhile thing to do, this is not going to have a significant effect on the amount of code involved. Each SoC will always require some amount of hardware specific code, whether or not that code is compiled alone or together with other SoC support.
- And very hardware specific code moved out to a controllable place, i.e. something like BIOS
Sorry, but I must vehemently disagree here. BIOSes are a problem for Open Source, not a solution. On X86 they use BIOS services only when there is simply no other choice, because the BIOS is too often buggy and it is more difficult and risky to update than the kernel.
If you rely on the BIOS to do X, it will work when the BIOS gets it right. If you do X yourself, it will work whether or not the BIOS gets it right. This means that if there's even one BIOS version you have to deal with out there that gets X wrong, you have to do it yourself and then there is no incentive to rely on the BIOS even in the cases where it does get it right so to maintain only one code path.
And relying on a BIOS could make many kernel improvements impossible to implement as the execution context assumed by the BIOS may not be guaranteed anymore (think about UP vs SMP, different preemption modes, different realtime kernel modes, etc.) And of course it is impossible to anticipate what execution context and requirements the kernel might need in the future, hence this can't be provisioned for (and much less validated) into the BIOS design in advance.
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:
- Merges support for more ARM SoCs and platforms
Sure. That's what I do with the Linaro kernel. And my policy when switching to the next mainline release is to _not_ rebase patches that appear unmaintained. In fact, I expect people to either have pushed their patches upstream, or rebase them to the next mainline version themselves, and if they don't do any of that then maybe those patches are just not worth it anymore and the best course of action is simply to drop them. So this temporary kernel tree _is_ the Linaro tree, and I'm making sure that nothing is kept latent for too long.
- Code for different SoCs and boards do not conflict and impact each
other, they live in a single branch
Absolutely. Otherwise people simply get lazy and careless. We _have_ to share the same branch as much as possible. And to answer Linus' criticism, we also have to _share_ as much code between SoCs and vendors.
- 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.
In that case it certainly can be merged in the Linaro kernel for this 2.6.38 release. When Linaro moves to 2.6.39 then someone will have to rebase those patches for Linaro's 2.6.39 release, and/or work on them towards upstream acceptance. but they won't be merged automatically into the next Linaro kernel if nothing is done about them in parallel.
Nicolas