On Sat, Apr 2, 2011 at 12:46 PM, Eric Miao <eric.m...@linaro.org> 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.
My argument is that patches won't rot here. Patches rot in a kernel tree that is derived from our member SoC's BSP and pushed nowhere and very few developers involved as a pet project. Yeah, this reminds me of the zaurus 2.4 kernel tree. But it's a different case here, we have our members involved, and what we are going to support are those boards that's widely available and there's a community working on, we definitely don't want to merge all the craps that could be out of maintenance. And that we provide a playground so the kernel is actually usable with Ubuntu or Android, which in the contrary makes it easier to test and validate and get the patches mainlined. But I don't believe what we're doing >> >> 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
