Slashdot Mirror
ARM Is a Promising Platform But Needs To Learn From the PC
jbrodkin writes "Linux and ARM developers have clashed over what's been described as a 'United Nations-level complexity of the forks in the ARM section of the Linux kernel.' Linus Torvalds addressed the issue at LinuxCon this week on the 20th anniversary of Linux, saying the ARM platform has a lot to learn from the PC. While Torvalds noted that 'a lot of people love to hate the PC,' the fact that Intel, AMD, and hardware makers worked on building a common infrastructure 'made it very efficient and easy to support.' ARM, on the other hand, 'is missing it completely,' Torvalds said. 'ARM is this hodgepodge of five or six major companies and tens of minor companies making random pieces of hardware, and it looks like they're taking hardware and throwing it at a wall and seeing where it sticks, and making a chip out of what's stuck on the wall.'"
All of which is, more or less, interchangeable. The Intel x86/IBM PC platform, despite its many flaws, has reached a stable point where there are well accepted and commonly implemented standards for the boot process, the storage formats, the hardware interfaces, etc. ARM, despite a "purer" and "simpler" instruction architecture, lacks much of this common surrounding infrastructure.
What is a desktop in the PC world is your SOC in the embedded world. It even comes with RAM and Flash (not on chip, but on package), if you want to.
The difference is that the PC environment has over a long time filtered down to a few typical devices for each type. Your network hardware is probably Realtek, or maybe Intel or an embedded AMD chip. You graphics card is NVidia, AMD or Intel. Your mouse does not matter, because it always talk USB HID etc.
In the ARM world, you also have standard components, but every integrator makes tiny (and usually pointless) changes that render them incompatible on the software level. Linus is right - this is neither necessary nor sustainable. It is one of the reasons that you can get software updates for a 5 year old PC, but not for a 6 months old smartphone.
They're not trying to cut corners for the hell of it, but for performance, power usage, and other actual engineering reasons.
You just cant build smartphones and tablets with that same common architecture, or else you're adding too many chips and circuits you don't need.
It's no big deal that PC's ship with empty PCI slots and huge chunks of the bios and chipset that are never used but rarely. (Onboard raid, ECC codes, so on and so on), but when you're trying to put together a device as trim and minimalist as possible, you're going to end up with something slightly different for each use case.
Goals for Friday.
1) play all pink floyd albums in a continuous loop.
2) make bubbly gurgle sounds with my "sandwich".
3) contemplate "making a chip out of what sticks on the wall".
Having to work for a living is the root of all evil.
The problem is that micro kernels have always been harder to develop and slower(if not done carefully). And not all "board features" can be separated/exposed from/to the kernel easily when done externally.
For instance, paging and memory management is usually something that would go in the kernel, even a microkernel. Do you know how many different ARM MMU interfaces there are, and also how many ARM processors don't have an MMU, or that implement only a subset of some other MMU. And then there is the dual-core processors now as well. I wonder how many different interfaces there are for controlling both multiple ARM cores or ARM processors.
Basically, ARM is a cluster fuck for OS development. They need some form of standardization if they ever hope to get widespread OS support. Linux is probably only supported by most boards because the board manufacturers submit patches to the Linux project. By widespread, I mean each board supporting a minimum of 3 different operating systems, for instance Windows, Linux, and something proprietary or a BSD.
I'm pretty certain he'd prefer a consortium that produces a common set of standards, but he raises an important point.
Choice costs.
It's wonderful that you have the a massively wide variety of choices, unconstrained by the a central authority, but don't forget that the cost of having that choice is going to be significant. There's a reason that almost all lines of business tend towards either a few big winners or, if the product is essentially identical, commoditization.
It's why I often wonder at why Linux users dream about taking over the desktop. If that did occur, it would mean a drive to lower cost that would result, almost inevitably, in the wholesale adoption of s single choice, reducing all the other choices to total irrelevance.
The difference is that the PC environment has over a long time filtered down to a few typical devices for each type. Your network hardware is probably Realtek, or maybe Intel or an embedded AMD chip. You graphics card is NVidia, AMD or Intel. Your mouse does not matter, because it always talk USB HID etc.
And perhaps most importantly your main system bus is either PCI or something that looks like PCI to software and by accessing the configuration space of that bus you can read the device IDs of everything on it whereas with ARM the software is expected to know the complete hardware setup in advance.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
You're missing the point. He's not talking about add-ons like network adaptors, he's talking about fundamental core bits of hardware, like interrupt and DMA controllers, which need to be configured by the kernel before it can even bring things like serial ports online for a console.
Every PC, except some early Intel Macs, is capable of booting PC-DOS 1.0. It has interrupt controllers and device I/O configured in the same way and accessible via the standard BIOS interface. You don't get great performance if you use these, but you can bring up a system with them and then load better drivers if you have them. With ARM, every SoC needs its own set of drivers for core functionality long before you get to things like video or network adaptors. Oh, and on the subject of video, you don't even get something like the PC's text console as standard, let alone a framebuffer (via VESA).
I am TheRaven on Soylent News
Microkernel versus monolithic kernel has nothing to do with board support packages.
Linux has the equivalent of "board support packages" -- they can be as small as one file, but are more often just a handful: a C file that describes memory and I/O mappings and other peripherals that cannot be safely detected at runtime, sometimes a default configuration (defconfig) file, and maybe some other pretty small driver-like files that manage some of the mess that Linus was talking about. (For example, the BeagleBoard has three C files: one to define the board, one to manage LCD video configuration, and one for audio setup; it shares a defconfig with every other board using an OMAP2/3/4 CPU.)
That is in sharp contrast to my experience with commercial RTOSes, where a BSP might consist of a dozen C source and header files, plus another half-dozen configuration files. For the boards I have used, Linux has the smallest set of board-specific files, a microkernel RTOS has the next smallest, and a Unix-based RTOS has the largest. Linux doesn't call its board-specific file sets BSPs because they are (a) too small to really call a "package" and (b) not controlled and shipped separately. (Linux is not about locking down what the end user can do, so there would be no point in having BSPs for officially supported boards.)
Is Linus Torvalds (implicitly, at least) criticizing ARM because it is open and therefore anyone can create their own version of it? As opposed to x86, which has a restricted licensing set (AMD/Intel/Via... Via still exists, right?)? Because that is, AFAICT, exactly why ARM is so varied: anyone can roll their own. With the result that many do.
ARM is not any more "open" than x86. To sell chips implementing modern versions of either instruction set, you must obtain a license from at least one company and nothing prevents you from extending that instruction set. Many companies have implemented (and often extened) each set over the years, though there are fewer implementing x86 now than ARM. There are probably fewer implementors of x86 because it is much more complex.
I think Linus is criticizing the lack of a common platform surrounding ARM rather than the instructions themselves. The instruction set of x86 chips has grown a lot, especially with x86_64, but the way you boot a PC hasn't changed much for example.
It is NOTHING like computers in the 70s and 80s.
In the 80s, you had machines made out of standard 3rd party components. Your CPU was the same as the next guy even if he got his computer from a competing brand. This is why an Atari could emulate a Mac. The actual CPU was a particular part that everyone bought from the same place. This is why you can have versions of Linux targeting those 80s/90s era machines. A 68000 in one machine is the same as the next, or a 6502, or a 68030.
The old home computer landscape seems positively orderly by comparison.
A Pirate and a Puritan look the same on a balance sheet.
Exactly.
The problem is not that adding support to a new board in Linux is too hard, in fact, it's almost the opposite. There are already tens of slightly incompatible boards to support, and every time a company makes a new one, they don't even try to stick to any standard (not that there even *exists* a real standard), since it's very easy to just add new code to Linux. See this LKML thread for Linus's description of the problem from some time ago.
Using a microkernel doesn't help at all; you still have to code for all of the slight incompatibilities, regardless of whatever differences in logical organization.
The CPUs were standard, but little else was. Sure, the C-64 and Atari 800 both had a 6502-based CPU, but they also had different video chips, different sound chips, different and mutually incompatible disk drive formats and serial communications protocols, etc. One nice thing was that even though each company used their proprietary chips, they didn't feel the need to hide implementation details from users. If you wanted to know exactly what each register in the VIC-II chip did, it was right there in the manual.