Android and compatibility with deprecated armv7 instructions

[Arnd Bergmann]

On Thursday 03 July 2014 18:32:26 Will Deacon wrote:
> On Thu, Jul 03, 2014 at 06:05:58PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Jul 03, 2014 at 05:22:30PM +0100, Grant Likely wrote:
> > > 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*.
> 
> We've never pretended to support anything other than ARMv8 in the compat
> layer. uname even reports this in the machine name.
> 
> If people are suddenly so concerned about *full* compatibility with an ARMv7
> kernel, that needs a lot more than just SWP emulation:
> 
>   - Alignment fixups for ldm/stm
>   - SETEND
>   - CP15 barriers
>   - SWI breakpoints + branch through zero syscalls
>   (- SWP)

Thanks for the list. Of course we would only have to support the ones
that anybody is using on ARMv8. We know about SWP and I suppose SETEND
as well, cp15 barriers are likely to be needed by someone, and I have
no idea about the others.

Do you know if it's actually technically possible to emulate all of
them? E.g. does ARMv8 allow implementations that cannot switch endianess
at all?

> By the arguments presented so far, I can't see why we wouldn't also need
> OABI too. In other words, where do we draw the line? If we're not completely
> compatible, then the compatibility argument suddenly becomes subjective.

As I just said in the other thread, OABI is pretty clearly on the other
side of the line. Same for NWFPE and BINFMT_AOUT (you removed the latter
on ARM32 already).
 
> It seems that people really want us to implement the subset of the ABI which
> is needed by the Google Play store and are trying to dress that up as the
> ARMv7 kernel ABI. The latter is a lot more work and conflating the two isn't
> especially helpful.

Right. This should be about keeping users from getting mad at us (or at
people using our kernel, who then get mad at us), not about strict adherence
an ABI if nobody cares about it.

	Arnd