Android and compatibility with deprecated armv7 instructions

[Russell King - ARM Linux]

On Thu, Jul 03, 2014 at 05:22:30PM +0100, Grant Likely wrote:
> On Thu, Jul 3, 2014 at 11:41 AM, Catalin Marinas
> <catalin.marinas at arm.com> wrote:
> > (I've been away for a day and missed all the fun ;))
> >
> > On Wed, Jul 02, 2014 at 11:14:47PM +0100, Grant Likely wrote:
> >> Android is not the embedded world where we could get away with a whole
> >> lot. There is a *freaking huge* installed base of applications.
> >> Breaking them is not an option, and I think Colin's question makes it
> >> clear that Android is going make sure that doesn't happen regardless
> >> of what the mainline kernel does... and they are right to do so.
> >
> > I don't know how huge this installed base of applications is. AFAIK,
> > it's limited to a (maybe significant) number of Android games all based
> > on certain library which no longer uses SWP in its recent releases. I
> > may be wrong but the information I have so far is that this huge base of
> > applications does not go beyond Android. Furthermore, people getting a
> > new Android phone with ARMv8 will have to re-download applications
> > anyway, so the currently installed base does _not_ matter. What matters
> > is what is provided in the Android _app store_.
> 
> Okay, I have to bite on this one....
> 
> Ah, no. The installed base *does* matter. Breaking things under the
> assumption that they can be fixed with an update is a horrible reason
> for breaking stuff. That creates hell for developers.
> 
> The first indication they'll have that something is wrong is they'll
> start getting negative reviews in the Play store ("This software is
> ****, it crashes immediately"). Then they've got to figure out why
> things have gone wrong. It won't necessarily be obvious that the
> complaining users have v8 hardware. Obtain a v8 device, and then
> figure out how to update all of their affected apps. During that
> entire time their app is broken and they are getting blamed by users
> for putting out crap software. And that assumes that the app is
> actively maintained. Multiply this by every affected developer.
> 
> Then there are the apps that work just fine, but don't have any active
> maintenance, either because it is an old project that doesn't have a
> team on it anymore or the vendor has disappeared. Do you really think
> it is okay to break working apps that are probably not going to get
> updated?
> 
> Third, there are side loaded apps. An update may not be readily or
> easily available. The Play store is not the only game in town. There
> are also kioskified Android devices that are basically stock, but have
> a custom application installed on it. There is also the Amazon app
> store.
> 
> Finally, stating that "the developer can just fix it" is a huge
> assumption. You're basically saying every app development shop has
> extra resources to go back and fix things in their older apps.
> 
> So, no. I completely reject any notion that breaking existing apps is
> okay. If we're going to say that v8 still supports 32-bit apps, then
> it has to be all of v7, not just the 'good' bits. Nor do I think
> saying "it's just a bunch of games" justifies anything. We're kernel
> engineers. Applications are applications and we don't break userspace.
> Period.

+1 on all points above.  I'd go further - if we're going to say that v8
still supports 32-bit apps, that covers at least v6 *as well*.

For reference, the full story on SWP is:

- present in all ARMv4, ARMv5 CPUs
- deprecated but still present in ARMv6, ARMv7 CPUs
- optionally present in ARMv7VE CPUs

The ARM ARM doesn't positively identify what an ARMv7VE is, but my
guess would be ARMv7 with the virtualisation extensions.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.