Why bother supporting ARM?

One of the things that came out in the original discussion is that the Fedora project did not have any idea of how to do that. Over its entire history, the project has never before seriously considered moving one of its secondary architectures to primary status. So there are no procedures in place and no criteria by which a decision to promote an architecture can be made. So, unsurprisingly, the project decided that it needs to come up with a set of reasonable criteria. On April 2, Matthew Garrett posted a draft showing what those criteria might look like.

The rules would appear to make sense. The Fedora infrastructure and release engineering teams need to have people who are able to represent any new primary architecture. The project must be able to build packages on its own servers. Anaconda, the Fedora installer, must work on the targeted hardware. Maintainers of important packages must have access to the supported hardware so they can fix problems. No binary blobs. And so on. Also required is approval from various Fedora teams, each of which can impose additional criteria if it sees the need. These rules are in an early form and can be expected to evolve over time, but the early responses on the mailing list suggest that most people are happy enough with what has been set down.

That said, there are clearly some people who do not see the point of supporting ARM as a primary architecture, and they have a number of reasons for their reluctance. The ARM architecture is messy, for example. The x86 architecture does not have a single design authority, but processors made by multiple vendors still resemble each other closely enough to create a fairly tightly-knit processor family. ARM does have a central design authority, but that authority leaves a lot of significant details up to individual manufacturers, of which there are many. So ARM is not a tightly-knit family; it is more like an extended group of hostile ex-spouses and in-laws who have moved to different continents to get away from each other.

The looseness of the ARM "platform" had led to a lot of innovation in the design space; there is no end of interesting ARM system-on-chip designs with all kinds of impressive integrated peripheral devices. But this diversity, along with a distressing lack of hardware discoverability, makes it impossible to create a single kernel that works on all (or even a significant subset of) ARM processors. Distributors hate having to maintain multiple kernels, and they hate having to put target-specific hacks into installers. ARM currently forces both, despite the ongoing work to consolidate kernel code and move hardware knowledge into the bootloader-supplied device tree structure.

ARM is also, for many developers, a relatively obscure architecture lacking the familiarity of x86. The fact that there are vastly more ARM systems running Linux than x86 systems does not really change that perception; most of us lack ARM-based development systems on our desks. Additionally, ARM processors are relatively slow. That is a problem for developers, who typically need to keep an x86 system and a cross-compiling toolchain around to be able to get through more than one edit-compile-test cycle in any given day. That slowness is also an issue for distributors; it can delay security updates and distribution releases, even for other architectures. And, while the hardware is slow, product cycles are fast; by the time developers have gotten a target working nicely, it may be obsolete and off the market.

Given all of these challenges, it is not surprising that some people would rather not be bothered by an architecture like ARM. The x86 world provides plenty of open, high-performing systems with wide support; why get distracted with that messy architecture where, even if the distribution can be made to work, the hardware is probably closed and won't allow it to be installed?

The answer, of course, is that said messy architecture is already performing much of our computing, and it will likely be doing more of it in the future. Traditional PC-style systems are no longer the center of attention; one assumes they will not go away entirely, but a lot of the action is elsewhere. There is a whole new crowd of makers looking to do interesting things with ARM-based designs; we are just beginning to see what can be done with interesting mobile devices, and the bulk of those devices are not, at this point, using x86 processors. Meanwhile, ARM has its eyes on data center applications where, some think, its compactness and power efficiency will make up for its lack of speed. The x86 architecture will be with us for a long time - even Intel has proved unable to kill it off in the past - but it is far from the only show in town.

It is also worth remembering that, for all its success, Linux is still a minority player on x86 systems. But Linux is the dominant system on ARM-based systems. The "year of the Linux desktop" may be an old and sad joke, but the year of the Linux gadget looks to be happening for real - again.

Given that ARM is where much of the action is, it would make sense that a Linux distribution - especially one that is supposed to be leading-edge and forward-looking - would want to support ARM as well as possible. Solid support for the architecture seems like a necessary precondition for any sort of presence in the interesting computing devices of the near future. Distributors like Ubuntu appear to have come to that conclusion; they have built on Debian's longstanding ARM support to create a distribution that, they hope, will be found in future devices. Without well-established ARM support, Fedora - along with the distributions derived from it - has little chance of competing in that area.

So one might well say that the questions being asked in the Fedora community are wrong. Rather than asking "why should we support ARM when it presents all of these difficulties?", it might make more sense to ask "how can we address these difficulties to provide the best ARM-based distribution possible?". The cynical among us might be tempted to say that Red Hat, Fedora's sponsor and main contributor, faces a classic disruptive technology problem. ARM is unlikely to displace x86 in the places where Red Hat currently sells support, and revenues from any future ARM-based "enterprise" distribution seem likely to be rather lower than those obtained from x86-based distributions. So it would be understandable if Red Hat were to show a lack of enthusiasm for the ARM architecture.

The cynical view is, at best, only partially right, though. Red Hat does not advertise the resources it is putting into ARM distribution development, but it clearly has a number of engineers on the task. Even as a "secondary" architecture, Fedora's ARM distribution has been solid enough to serve as the base for the ARM-based OLPC XO 1.75 laptop. Without Red Hat's support, there wouldn't be a Fedora ARM distribution even with secondary status. So it seems unlikely that Red Hat is the sticking point here, even if its contributions to the kernel's ARM subtree (29 patches total from 3.0 to the present) show little enthusiasm. More likely we're just seeing the usual noise as the wider community comes to terms with what will be required to support this architecture properly.

In the end, the world would not be well served by a single processor architecture; there is value in diversity. Similarly, an industry where ARM-based systems are dominated by Android variants may not be the best possible world. A lot of interesting things are happening in computing, and many of them involve the ARM architecture; there is a lot of value in having strong community-based distribution support for that architecture. That is why Fedora will, in the end, almost certainly bother to support ARM as a primary architecture despite the challenges it presents.