ARM Is a Promising Platform But Needs To Learn From the PC 167
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.'"
Re:Wait, what? (Score:4, Informative)
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.
Re:Wait, what? (Score:4, Informative)
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).
Re:That's the trouble with a monolithic kernel (Score:5, Informative)
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.)
Re:That's the trouble with a monolithic kernel (Score:5, Informative)
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 [gmane.org] 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.
Re:That's the trouble with a monolithic kernel (Score:3, Informative)
and so it has to be hacked all over the place to deal with architecture variations.
Bullshit. Linux abstracts such details though various standardized functions and macros. If you've bothered to pull your head from your ass and take even a quick look at the Linux source tree, you can clearly see the architecture variants are cleanly broken out.
Not only is your post NOT "Interesting", as was modded, it is factually, "Troll".