What's Up With ARM

Over the course of the last month or so, numerous people have asked me for my opinion on what’s going on with the ARM architecture in Linux. It seems time to broadcast those thoughts more widely. For those who don’t want to read the whole thing, the short version is this: Linux on ARM is a victim of its own success and, as a result, is going through some growing pains. That has created a lot of noise, but all that’s really needed is a bit of house cleaning.

ARM processors are generally found in embedded applications; your phone, network router, video camera, and more are quite likely to be running Linux on ARM. Supporting ARM on Linux brings some challenges which are much less of a problem on desktop and server-oriented systems. ARM is not so much an architecture as a family of architectures with lots of little quirks; the size of the kernel’s ARM-specific code – nearly three times the size of the x86-specific code – reflects that. ARM also has traditionally suffered from the “embedded problem”: every vendor does its own work and, likely as not, never gets around to contributing its code upstream. That has resulted in a lot of fragmented and duplicated code.

Thanks to an ongoing effort by the Linux Foundation and a great many developers, the embedded community has become increasingly aware that its interests are best served by getting its code upstream. Contributions to the kernel from embedded systems companies have increased greatly; a number of these companies now feature prominently in the list of top-20 contributors. This is very much a good thing – it is exactly what we have been wishing for all these years.

But the fact remains that a lot of this code was developed in isolation, without community input, and the developers involved often do not have the time to improve it. Oversight over the ARM tree has not always been as good as we would like; there are many diligent and attentive ARM maintainers, but the job has simply gotten too big for them. So the kernel has accumulated a lot of code which duplicates functionality and which does not share consistent, higher-level abstractions. In short, it’s a bit of a mess.

One thing we have learned is that this kind of mess, if allowed to continue to get messier, leads to increasing maintenance problems and eventually collapses under its own weight. The development community is both able to see that kind of problem coming and willing to do what it takes to remedy the situation; that is part of why Linux remains viable and successful after twenty years of development. In this case, Linus Torvalds has been pushing for a higher level of discipline in ARM development for a while. He has made it increasingly clear that he wants to see a change in how that code is managed and he is willing to delay the merging of new code in the ARM tree if that is what’s required to change things.

What needs to happen is pretty clear: we need more eyes on the ARM code, some determined work to clean up what is there now, and better high-level support to facilitate the addition of clean code in the future. Much of this work is already happening; the 2.6.40 kernel will certainly include a number of patches which consolidate duplicated functionality and make the code base smaller. There will be more review and guidance for embedded systems developers (who are often not full-time members of our community) as they work to get their code upstream. As the result of all this, we may well see the size of the ARM tree shrink, even as it gains functionality and supports more hardware.

The kernel community has had to clean up messes before; indeed, there will probably always be a number of messy areas in the kernel source tree. That is the nature of a project which routinely accepts tens of thousands of changes from thousands of developers. The ARM mess is not small, but it’s really just another cleanup job of the time that we have done many times in the past. What is going on with ARM is a good thing; we are developing the code and processes we need to deal with rapid growth in what has become one of the most important architectures that the kernel supports. As we find ourselves increasingly surrounded by ARM-based Linux devices, we will all benefit from this cleanup exercise.