| |||||||||||||
LFCS: ARM, control groups, and the next 20 yearsLFCS: ARM, control groups, and the next 20 yearsPosted Apr 13, 2011 16:57 UTC (Wed) by cpeterso (guest, #305)Parent article: LFCS: ARM, control groups, and the next 20 years
> There are 70 different sub-architectures and 500 different SoCs in the ARM tree.
Perhaps the cleanest and/or most popular ARM sub-architecture should be blessed as the primary platform code (like the x86 32/64-bit merge). If the other sub-architectures don't want to play, they can be developed out-of-tree. If a sub-architecture is only used by its developer, then who benefits from it being included in the Linus tree?
(Log in to post comments)
LFCS: ARM, control groups, and the next 20 years Posted Apr 13, 2011 19:04 UTC (Wed) by mrfredsmoothie (subscriber, #3100) [Link]
The next guy who wants to ship a product w/ the same SOC (or peripherals).
LFCS: ARM, control groups, and the next 20 years Posted Apr 13, 2011 21:17 UTC (Wed) by drdabbles (subscriber, #48755) [Link]
I suspect the important difference between the ARM arch and the x86 arch is that there are gobs of generic x86 systems out there with the same exact cpu in them, and with a roughly equivalent basic bill of materials.
In the arm space, there are loads of custom parts. Custom CPUs, custom boards, etc. Very little is the same across multiple devices, which makes it very difficult to have a generic platform to bless as your standard. In fact, there are still ARM chips in heavy use that have no MMU.
This can most easily be seen by building a defconfig for an x86 system and booting it and trying to build a defconfig for an ARM device.
LFCS: ARM, control groups, and the next 20 years Posted Apr 14, 2011 6:06 UTC (Thu) by james (subscriber, #1325) [Link]
Also, I understand that most of the x86 platform has discoverability built in, so various OSes (possibly user-installed) can work out what's in the system and how to use it. On most ARM systems, that's an unnecessary expense and power draw, since it can be hard-coded in the highly-constrained software environment.
LFCS: ARM, control groups, and the next 20 years Posted Apr 14, 2011 13:24 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
ARM keeps tighter control of their architecture than Intel has ever been able to with x86. Very few commercial ARM cores have been designed outside of ARM. The problems are mostly outside the CPU, and they lie not so much in customisation (though there is much apparently pointless wheel-reinvention) but in lack of discoverability.
Most platforms have basic devices like an interrupt controller and interval timer that can just be assumed to be present. On x86 you get a PIC or APICs and a PIT or HPET. The newer versions even have backward-compatible modes. On ARM there are a wide variety of interrupt controllers and timers, and no reasonable way to probe for them. The boot loader is supposed to tell the kernel which type of machine it's booting on, and sometimes the system vendor even gets this right... but AFAIK the kernel isn't yet able to initialise the right set of drivers based solely on that.
LFCS: ARM, control groups, and the next 20 years Posted Apr 14, 2011 18:54 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
actually, in the discussion on linux kernel it was proposed to make the bootloader pass this information to the kernel, and there was a large amount of opposition from many of the ARM people to this suggestion.
based on this I don't believe that it works that way today.
LFCS: ARM, control groups, and the next 20 years Posted Apr 14, 2011 23:28 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
It does work the way I said: the boot loader passes in a machine type number. But the kernel still has to have a built-in definiton of each machine type.
The current discussion is about having the boot loader pass in a fuller machine description (the Device Tree). This may simply be tacked onto the end of the kernel image in some way, so there is no need to modify existing boot loaders.
LFCS: ARM, control groups, and the next 20 years Posted Apr 15, 2011 18:11 UTC (Fri) by p2mate (subscriber, #51563) [Link]
I would argue it's the other way around. There are only 3 companies who can make modern x86 cores: Intel, AMD and VIA. Intel doesn't license the necessary patents to others (besides those 2) to allow them to make x86 cores. Anyone with enough money can buy an ARM architecture license though which allows making your own core. At least the following companies have at some point made their own cores or modified the ones provided by ARM : Digital, Intel, Marvel, Qualcomm, Samsung and more companies are working on new cores.
LFCS: ARM, control groups, and the next 20 years Posted Apr 14, 2011 2:26 UTC (Thu) by xxiao (subscriber, #9631) [Link]
maybe, it's time to switch linux's focus to ARM instead of x86 these days.
I hope Linus works at Linaro to achieve this shift. LF is basically an Intel shop, though I could be wrong.
LFCS: ARM, control groups, and the next 20 years Posted Apr 14, 2011 16:20 UTC (Thu) by cpeterso (guest, #305) [Link]
Someone should give Linus shiny new ARM workstation. Then the ARM hassles will be _his_ hassles (and they will get fixed). ;)
LFCS: ARM, control groups, and the next 20 years Posted Apr 15, 2011 14:20 UTC (Fri) by mrfredsmoothie (subscriber, #3100) [Link]
Are you taking donations? ;-)
LFCS: ARM, control groups, and the next 20 years Posted Apr 16, 2011 14:38 UTC (Sat) by oak (subscriber, #2786) [Link]
It's unlikely to replace his x86 workstation as x86 has the performance lead. ARM leads on power efficiency which is important for mobile & battery powered devices, but I don't think kernel devs are going to be doing their development (and builds) e.g. on their phones... :-)
|
|||||||||||||