On Sat, 2 Apr 2011, Eric Miao wrote:
> 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.
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:
>
> 1. 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.
> 2. 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.
> 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.
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
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
