On Fri, Apr 1, 2011 at 11:43 PM, Eric Miao <eric.m...@linaro.org> wrote: > Just FYI - lengthy but very interesting read, Linus was really good at > wording, enjoy heh :-) > > https://lkml.org/lkml/2011/3/17/283 > > So maybe it's just a right time to talk about using linaro ARM kernel > tree as a fork for quick merge of the ever expanding SoC and board > support, and using it more as a productive kernel for downstream. > And in the mean time, improve the mainline kernel into such a good > shape that with less crappy code we could support more platforms? > > Just a bit thought on that possibility. >
Yeah, I've discussed with Eric 2 days ago after I was shocked by this email flame about our ARM community. Generally, I do think it's a good time for our Linaro guys to consider necessary actions, since Linaro is a neutral place for all ARM Linux related parties and we are trying to make upstream kernel better and benefit for every ARM Linux players. So a) firstly, I suggest we need discuss widely why Linus blamed us (the problem we are facing here). I think if we followed the email thread we can buy the conclusion (if I'm wrong, please correct me): ARM kernel need some kind of platform layer (not ARM core layer ARMv7/ARMv6) abstraction or unification. And our goal is make our SoC sub arch code more cleaner and more containable, or support single binary kernel for ARM machines (magic to me). For deeper investigation, I think Nico pointed out some abstraction areas such as GPIO, irq_chip, PWM (from Uwe), other fundamental areas and etc. We definitely need a working item list for this. Maybe we will realize this working list is too large, then we might go back to talk about a fork or a mach-nocrap (from Arnd). >From my POV, ARM Ltd. can help get some information from popular IP vendors and encourage them to upstream their code. I worked on Blackfin arch before which sharing MUSB IP with OMAP/Davinci, thanks god, we got an initial version Linux driver of this IP from Mentor, finally all MUSB IP licensees are sharing the same driver in kernel (Blackfin/OMAP/Davinci, maybe more) although this driver is painful. And for the IP vendors they do provide Linux drivers, if their code is in upstream already, SoC guys can easily reuse the code and we can make the IP driver more sharable and maintainable. Moreover, since more and more ARM SoC will join our ARM kernel family and more and more manufacture will produce ARM based products, how do we deal with those new comers and new boards/maches. b) For our Linaro kernel guys as a part of ARM kernel community, I suggest we take over these working actions and we do have engineer resource to do that or encourage more people to join this work. - choose several experienced Linaro kernel forks to form a ARM kernel platform maintainer team (RMK is still our ARM arch core maintainer) to review platform code, do abstraction and unification, do documentation for new comers and encourage SoC code to follow our solution. - announce this team and our plan/project widely and publicly to let ARM kernel community and Linus know it - setup a suitable kernel tree or process to make this happen, like arm-linux-platform tree or project to contain code and push them to upstream - help each SoC maintainer to isolate their code and not introduce conflicts on platform level Just some basic thought, hope we can come our some real solutions and make Linus just merge without any complains, -:)) Thanks, -- Bryan Wu <bryan...@canonical.com> Kernel Developer +86.138-1617-6545 Mobile Ubuntu Kernel Team Canonical Ltd. www.canonical.com Ubuntu - Linux for human beings | www.ubuntu.com _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
