Red Hat: ARM servers will come when people crank out chips like AMD's 64-bit Seattle

Standards to lift data center boxes out of device doldrums

LinuxCon 2014 It's practically a given that the ARM processor architecture – so beloved by makers of small devices everywhere – will graduate to servers soon. But before ARM servers can ship in any significant volume, a standardized hardware platform that specifically targets the data center is a must.

So sayeth Jon Masters, chief ARM architect for enterprise Linux giant Red Hat, who addressed the topic during a session at the LinuxCon 2014 conference in Chicago on Thursday.

Red Hat and others – most notably the Linaro consortium, of which Red Hat is also a member – have been working on getting Linux ready for ARM servers, and vice versa, for several years. But according to Masters, one challenge has been convincing hardware vendors that what has worked for ARM on mobile devices won't work for the data center.

"A lot of early servers – not just in the ARM case but with other architectures – were built using what I call an embedded mindset," Masters said. "So they continue what I affectionately call the 'embedded zoo,' which is really applying the design philosophy that you take with a mobile phone and applying that to a server."

Red Hat's Jon Masters

Red Hat ARM architect Jon Masters says you can't have 64-bit ARM servers without hardware standards

It's not that Masters sees anything wrong with how phone vendors have been building their devices. He admits that the embedded design philosophy has served Apple and the various Android mobe-makers extremely well.

But these efforts have been successful in large part because smartphone vendors build their kit so that the software is "welded" to the hardware as a fully integrated system. Whether they use an off-the-shelf ARM system-on-chip (SoC) component or they create their own – as Apple and Samsung have both done – each device they produce typically contains numerous software adaptations for its own, specific hardware.

Reinventing SoCs for the data center

The concept of highly integrated, power-conserving SoCs can also be a huge boon to the data center, Masters said. But having each chipmaker design its SoCs to totally different specifications, the way they do for the embedded market, is just no good for servers.

"General purpose computing platforms differ from embedded systems," he explained. "Software does not ship with the hardware. They're not welded together. People buy hardware from their vendor of choice, and then they go get their operating system from their vendor of choice, and they need that to work."

"If I've got 20 different possibilities for wiring up a serial port on a server, there's a problem."
– Jon Masters, Red Hat

We're not just talking about choosing between Linux and some other OS here, either. When today's IT admins buy a server, they also expect to be able to wipe whatever Linux distribution it came with and install another one, if they want. Yet with ARM SoCs designed for the embedded market, there's no such guarantee.

"There's no standard that tells you, for example, 'here's exactly how the system is going to boot, here's how you're going to find the kernel'," Masters said. "Not 'on this board go here and on that board go there,' but 'here's one way to do it.' There isn't that in some of these embedded technologies."

Masters doesn't believe that the software solutions developed for the embedded market – like the Device Tree and the U-Boot universal bootloader – are the right way to go for servers, either. They simply don't provide enough abstraction above the hardware to allow admins to treat ARM servers interchangeably, the way they do their existing x86 boxes.

"What we need instead are standardized hardware devices. In order to boot the system that we're using, we have to have a certain level of standards, going in … If I've got 20 different possibilities for wiring up a serial port on a server, there's a problem," Masters said.

Next page: ARM steps up

Biting the hand that feeds IT © 1998–2021