On Wed, Jan 07, 2015 at 08:48:48PM +0100, Arnd Bergmann wrote:
On Wednesday 07 January 2015 12:44:56 Jon Masters wrote:
On 01/07/2015 12:27 PM, Mark Brown wrote:
That level of hardware compatibility does partly come from the need to run existing software. I'd expect that similar effects will start to come into play with ARMv8 ACPI systems if they become successful; people will do things like ensure compatibility with common IPs that have existing Linux drivers that distros tend to include as standard.
Agreed.
There are two problems I see in trying to do the same thing on ARM:
- we don't have a single vendor that makes de-facto standards that everyone else has to copy in the way that the few remaining x86 vendors copy everything that Intel does. In fact, we prefer to have a large number of independent vendors.
Right, I'd guess that (modulo any standards being defined and becoming successful) it'll more be a case of vendors keeping compatibility with their own stuff. We *are* seeing greater reliance on off the shelf IPs for more boring things like DMA and basic bus controllers but there's plenty of other areas that still affect servers.
- There is a general mindset about deprecating unwanted features early. ARMv8 aarch32 bit mode removes support for older instructions or makes them optional. Even the virtualization mode doesn't allow to trap on architecture version specific differences, so you can't completely emulate an older architecture level. This is nice for implementers but not so much for users that rely on old (mis-)features. It's also not just the CPU core, other components also get easily replaced, like a GICv3 that is not a strict superset of GICv2.
This is indeed worrying, though hopefully the fact that we're already seeing negative impacts in the app ecosystem for Android will have focused some minds - once you're talking about full system images it gets even more fun.