This week KernelTrap interviewed Russell King, who originally ported Linux to ARM and continues to oversee ARM Linux development. Russell talks about ARM, the 2.4 kernel, the upcoming 2.5 kernel and much more...
Please share a little about yourself and your background...
I'm 28, living in Surrey, England. I've always had a keen interest in
electronics and computers. I was educated at Reigate Grammar School,
and moved on to Southampton University.
How and when did you get started with Linux?
I started hacking on Linux for my Acorn A5000 machine back in Spring
1994 while still at Southampton University, after a fellow student,
Martin Ebourne, introduced it to me.
An A5000 is a desktop-like ARM based machine. It was already about 3
years old and underpowered at that time, with only 4MB of RAM but it
was the machine I had.
What are some of the contributions you've made?
I ported Linux on to the ARM3 processor (as used in the A5000) single-handedly, including user space. There is a long story behind this,
which can be read on my website, http://www.arm.linux.org.uk/. Later
on, Martin Ebourne ported it to his later ARM710 based RiscPC. Back
in those days, Linux was built under the native operating system, and
utilities like diff and patch didn't exist. Consequently Martin's work
didn't make it back into my tree. I later ported it to the Digital
EBSA110 StrongARM evaluation platform, and then to a StrongARM RiscPC
kindly donated by Acorn. At this point, the general structure of the
ARM Linux kernel was set.
The main area that I'm now involved in is handling the ARM port of Linux,
which basically means receiving patches from the various ARM developers,
integrating them together cleanly, and making sure they all co-operate.
I've also been involved in restructuring the partition support in 2.4
kernels, as well as the core busmouse driver.
Looking forward, I also provide a home for the CPU clock speed scaling
project, which is being used by both the x86 and ARM architectures,
and a replacement UART subsystem for the kernel.
Power management is important in battery-operated machines like the
Compaq iPAQ and x86 laptops. The power used by the processor is
related to the speed at which it executes instructions and hence the
clock rate; the slower the clock, the less power consumed. You want
to be able to adjust the CPU clock rate such that you get good
performance from the machine, and good battery lifetime.
In some applications, user space has an idea of what will be happening
in the future, and on embedded devices, this allows very precise control
over the power used, such as the Delft University of Technology LART project
What are some key differences between the ARM port and the main iX86 branch?
We have around 120 machine types, many of them quite different. It isn't
possible to build one kernel for everything, although we try to allow
a kernel to run on as many similar machines as possible.
What file systems are supported by the ARM port? Do you use any of the new
journaling file systems?
The usual collection of ext2, minix, cramfs, jffs, jffs2, fat, nfs and so
forth work without problem, and I'd expect the same from the other
filesystems. I am not aware if ext3 has been tested specifically on ARM,
but they should work without problem - the code has been audited for the
common portability problems like endianness.
ReiserFS has been run on the skiffcluster machines that handhelds.org run;
I am not aware of any specific problems they had with it.
Why would someone choose ARM Linux over the many other ports?
ARM machines can be cool - for example the iPAQ hand held PC, or the LART
(Linux Advanced Radio Terminal). The iPAQ comes with WinCE installed, but
the handhelds.org people give instructions how to load ARM Linux onto it.
How was partition support restructured?
The partition support was restructured back in the 2.3 days; in fact, the
work happened much earlier because it was necessary for the 2.2 ARM Linux
kernel. Acorn machines have many weird and wonderful partition formats,
and placing them all into the original genhd.c file was becoming very
It was decided between myself, Alan Cox and others that the partition code
should be split up into their individual types, and placed somewhere
reasonable like fs/partitions. For example, the usual x86 DOS partitioning
system is in fs/partitions/msdos.c, where as the Sun partitioning support
is in fs/partitions/sun.c
What main tools do you use when developing?
I normally use the MicroEMACS editor (sorry vi and EMACS people). I do
run X11 on my ARM-based workstation, with the usual Gnome environment.
I also run Mozilla, but that's running from an x86 laptop (keep that
The ARM kernel builds are done natively - across several machines. With so many ARM machine types, I am only able to build a small fraction of
those here for the machines I have.
What other operating systems do you use? What do you like and dislike about
them, compared to Linux?
I don't use any other operating systems now, but have used and setup
various version of Windows in the past, and dabbled a bit with a
Novell 4 fileserver.
I also used RISC OS, an operating system for Acorn machines for several
years. It has a co-operative multi-tasking graphical user interface,
which is very responsive, and had many applications but lacked facilities
However, for ARM based machines, Open Source is invaluable - you'll be hard
pressed to get Oracle for Linux running on ARM. With the source code
available, and time, there is the possibility to get anything working
on ARM. ARM does have some unique problems, but it wouldn't be any
fun if it didn't!
What are some of the unique problems you've faced?
ARM processors have different alignment rules for data types. For instance,
32-bit words should be aligned to 32-bit boundaries. The kernel network
code doesn't follow this, so we have to "fix up" these mis-aligned accesses
via special code.
ARM processors generally don't have floating point instructions - we
currently emulate them via a kernel mode emulator. There are other
solutions as well, like a soft-float implementation for user space
(where a library linked to the application provides the necessary
integer maths for handling floating point).
The caches on ARMs require special handling as well from the cache
consistency viewpoint. Our caches are tagged and searched using the
"virtual" address - the address that Linux and applications use. This
requires special cache management code to maintain consistency of data
when we switch processes or change memory mappings (eg, when mapping
Have you looked much at the various open source BSD kernels?
There has been the odd occasion when I've taken a peek to see where they
are, and whether the BSD people are still doing ARM stuff. People new to
Linux do ask about the Linux and BSD people sharing code, but there are
problems with this - mainly there are concerns over patents with the BSD
What reflections can you offer on the current state of the 2.4 kernel series?
Do you consider it to be stable?
The Linus 2.4 kernels are almost production quality, but there's still
some work to do on them. Alan Cox's 2.4-ac branch is basically there.
I switched the ARM community from Linus' kernels to Alan's around 2.4.8,
mainly because I wasn't happy about the direction Linus was taking.
Of course, we did find various problems with the VM, and Rik van Riel
was helpful in resolving them.
Alan has commented in his -ac changelog that he'll be switching to the
new VM at some point, in an effort to merge his branch with the main
tree. What do you think about this?
I think Alan will stay with Rik's VM until the Andrea/Linus VM becomes
stable. I don't believe that Alan will change the VM in his tree "just
to merge with Linus" since that is not the way to achieve stability.
Alan believes in making one small VM change at a time and testing its effect
out before applying the next change. This allows the effects of the changes
to be isolated and evaluated, and bad changes to be thrown out more easily.
What do you most look forward to in the upcoming 2.5 kernel? When do you
expect work to start here?
I'll start working on the 2.5 kernel as soon as it comes out - there is
quite a lot planned for 2.5 which will impact the ARM architecture quite
heavily - for instance, we are moving towards having a generic "driver"
structure to handle PCI, ISA, PnP peripherals. On some ARM machines, we
have our own "expansion cards", and we'll probably move this over to
the generic structure.
Hopefully, we'll be able to get ARM completely merged; there are some bits
that are only suitable for integration into the development series for the
main tree, but turn out to be necessary for ARM (these keep on appearing).
There are changes to the console and keyboard code in the ARM tree, which
would affect the behaviour of the other architectures. Also there are
changes to the PCI layer that allows Linux to take advantage of the "PCI
prefetchable" region. Before either of these can be merged, they really
need to be tested out on the other architectures to make sure that the
changes don't cause other stability problems.
Since we are in the middle of stable series of kernels, merging code that
changes the behaviour isn't a good thing.
The ARM port also has a few other projects - CPU clock scaling and serial
drivers. The CPU clock scaling should be mergable into 2.4, but the
serial drivers will definitely be a 2.5 merge.
Have you met Linus? Alan? Other kernel hackers?
I've met a lot of Linux people, including Linus and Alan, on several
occasions mainly at various conferences like the UK Unix User Group
Linux conferences, the Ottawa Linux Symposium, and the Kernel 2.5
Conference in San Jose this year.
The ARM community have also met once in New York, and we hope to have
further meetings in the future.
How large is the ARM community? How big a turnout did you have in New York?
It's difficult to tell. Intel, who organised the New York meeting had
many requests to attend, far more than the number of places that were
available. There are around 1000 on the ARM Linux mailing lists, but I
know a lot of people don't subscribe to them. In addition, there is
commercial interest in Linux on ARM processors.
There are other lists as well - at handhelds.org and the LART mailing
lists, which have a lot of people who aren't subscribed to the ARM Linux
What do you enjoy doing in your non-Linux time?
Up until a few weeks ago, I was working on the Jubilee Line project
(a part of the London tube transport network). Since then, I've
decided to take a break from the politics of major companies for a
while to return to sanity.
What tips and inspiration can you offer aspiring kernel hackers?
The rapidly expanding selection of Linux books provides useful
information. Certainly "Linux Device Drivers" is highly recommended.
Also, the #kernelnewbies channel on the Openprojects IRC network
(see http://kernelnewbies.org) provides help to budding kernel
Mailing lists are an invaluable resource to find out what the community
is doing, proposed features, and information regarding new releases.
There are many Linux mailing lists, and subscribing to the relevant
ones can be a nightmare, especially as some are high volume. Using
a mail client that understands threading helps.
I've switched email clients numerous times in the past couple of years. In
recent months I've been happily using Sylpheed, which supports threading and is
being rapidly developed. What client do you use and recommend?
Mutt is really good, but takes some time to get used to it. If you
used elm previously, you have an advantage in that many of the keys
are identical. I tend to think of mutt as "elm v10" - it has a lot
of really useful features elm was lacking. For instance, mutt
integrates mime and pgp (or gnupg) support, as well as the ability
to sanely postpone messages.
In our last interview with Robert Love, we learned about his preemptive
kernel patch. Could this patch, or the one maintained by Andrew Morton,
be applied to the ARM port of Linux?
Andrew Morton's patch doesn't apply cleanly to the ARM tree due to some
of the changes we have. There is one failure, which would be trivial to
fix up after the patch is applied. In addition, the patch would require
a minor modification to the kernel configuration scripts. Someone with
C and shell experience could manage to apply and run it without any
Robert Love's preempt patch is more involved - it touches some of the
i386 assembly files. These changes would need to be ported over to the
ARM assembly files, which means that it is probably only suitable for
an experienced kernel hacker with some knowledge of ARM assembly.
I don't have any specific plans to merge either of these with the ARM
kernel until I know the direction that we're going in - the preempt
patch is quite invasive into the generic kernel, and is not really
2.4 stable material at this point in time, in my opinion.
Is there anything else you'd like to add?
I'd like to thank various people at Acorn, ex-Digital, Intel,
netwinder.org, and the ARM community for the support that they've
provided, helping ARM Linux to progress to where it is today.
Links from this article:
Other related links: