Handling ARM architecture changes

Current Linux systems running on x86 processors will run binary programs created in the 1990s. A strong focus on not breaking the user-space ABI deserves much of the credit for this state of affairs, but there is another factor at play: the x86 hardware architecture has also been managed with an eye toward keeping old executables working. The ARM architecture is different, though; it evolves in ways that will prevent some older applications from running properly (or at all). That presents a challenge for kernel developers, who do not want to break applications but who also want to keep the kernel maintainable in the long term.

Recently, Colin Cross (of Google) raised an issue for consideration. The ARM architecture is occasionally put through a major revision, the latest of which is ARMv8. This version adds 64-bit support, among other things; it also provides compatibility support for applications built for older versions of the architecture. But that compatibility only goes so far; it lacks, in particular, support for the SWP instruction (which performed an atomic read-modify-write operation), the SETEND instruction (used for changing the endianness of data accesses), and certain types of barriers. This lack of support is not surprising; these features were all deprecated in v6 or v7 of the ARM architecture. ARM is following a well-established schedule in its removal of these instructions.

The problem, of course, is that there are applications out there that are still using those instructions. Any application that is built today should be free of deprecated instructions, but there are plenty of applications sitting in the dustier corners of the Google Play Store that have not been built recently, and which, perhaps, will never be rebuilt again. As things stand, if a user loads such an application onto an ARMv8 device, it will fail to run. That runs counter to the plan that ARMv8-based Android devices are expected to be compatible with existing applications.

The solution to the problem seems straightforward enough: the kernel can trap attempts to use the deprecated instructions and emulate them. Applications using those instructions will then continue to run, though they will run more slowly than they otherwise would. Colin asked if the kernel community would be willing to accept a set of patches implementing this emulation. The alternative, he said, was for Google to maintain the patches in a separate tree that all Android vendors would use; in this case, the mainline kernel would fail the Android compatibility test suite.

Given the importance of Android in the ARM world, one would think that there would be little opposition to keeping the kernel compatible in this way. But ARM developer Will Deacon expressed his opposition to the idea, complaining that, once emulation for instructions like SWP goes in, it will have to be maintained for a long time. He also argued that use of SWP, in particular, almost certainly indicates a bug in the application. It would be better, he said, to keep this code out of the kernel and to simply fix the affected applications.

Catalin Marinas added that anybody moving to an ARMv8 device is going to have to download all their applications from the store anyway. In his mind, Google should push to get older applications rebuilt so that, when users download them on their shiny new ARMv8 devices, they will simply work. But Grant Likely objected to this reasoning, saying that forcing developers to rebuild applications makes the platform as a whole more hostile. Also, he said, many of those older applications may no longer have a functioning company or developer behind them; getting them rebuilt may simply not be possible. But they work well enough now, and should not be broken.

After some back-and-forth, the conversation seemed to reach a point where most developers agreed that breaking existing applications is not a good thing. How that will translate into patches going into the mainline kernel is not yet entirely clear, though. The developers also reiterated the usual rule about backward compatibility: it is, in fact, perfectly fine to remove support for deprecated features as long as nobody is actually using that support. Given that ARM is likely to continue deprecating hardware features in the future, kernel developers are going to have to find a way to minimize support for deprecated features going forward. Nobody wants to turn the kernel into an emulator for all older versions of the ARM architecture.

To that end, Catalin put forward a proposed timeline for how to deal with deprecated features in general. The first step happens as soon as a feature has been deprecated in the hardware, but while current hardware still supports it. That is when the kernel community needs to find ways of calling attention to the deprecated feature and encouraging developers to move away from it. In particular, the right way to replace the deprecated feature should be worked out and publicized.

Step two comes about in the next hardware version, where, by ARM's normal practice, the deprecated feature is still available but can be explicitly disabled. At this point, the kernel will disable such features and emulate them in software; warnings will be emitted when the deprecated features are used by applications. Everything will continue to work (though maybe more slowly). There is one challenge here, in that it can be hard to get anybody to see kernel warnings on a mobile device; users tend not to read the log files often, if, indeed, they have access to the logs at all. For this type of device, warnings may have to be implemented at other levels; in the Play Store, for example.

In the third phase, another hardware revision has removed the feature entirely. At this point, Catalin says, the kernel should stop emulating the instruction and, instead, deliver an illegal-instruction signal (SIGILL) to the offending process. The emulation code might still be in the kernel, he said, but it should not be enabled by default. Finally, in the fourth stage, the emulation support would be removed altogether.

There appears to be widespread agreement in the ARM kernel community around this set of rules for dealing with hardware deprecations. There may, however, still be some dissent over the issues at hand today. It can be argued that the SWP instruction, deprecated in ARMv6, should not yet be at stage three because the effort to move users away from it was not made at an appropriate level. So, while some developers would still like to see applications rewarded with SIGILL for using SWP on ARMv8, it may be necessary to carry emulation for that instruction for a while yet.

For ARM hardware features that are deprecated in the future, though, the above timeline seems likely to be followed. As long as the word gets out to developers in time, there should, with luck, not be users of the deprecated features remaining by the time the support is removed entirely. That should help to keep the kernel maintainable as the hardware architecture evolves. But it will be disappointing to those who wish they could carry forward applications from their old G1 phone and have them run properly on future devices.

Index entries for this article
Kernel	Architectures/Arm
Kernel	Development model/User-space ABI

---

to post comments