Linus being annoyed by the ARM kernel code
bryan.wu at canonical.com
Mon Apr 4 05:38:33 UTC 2011
On Fri, Apr 1, 2011 at 11:43 PM, Eric Miao <eric.miao at linaro.org> wrote:
> Just FYI - lengthy but very interesting read, Linus was really good at
> wording, enjoy heh :-)
> 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
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
- 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
- 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, -:))
Bryan Wu <bryan.wu at 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
More information about the linaro-dev