From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: Android and compatibility with deprecated armv7 instructions
Date: Thu, 3 Jul 2014 19:40:17 +0100 [thread overview]
Message-ID: <20140703184017.GB21086@arm.com> (raw)
In-Reply-To: <6860270.v9z8a8Se80@wuerfel>
On Thu, Jul 03, 2014 at 07:23:41PM +0100, Arnd Bergmann wrote:
> 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?
You can set SCTLR.E0E on exception return to change the endianness of
userspace, but there could be some `gotchas' with SETEND and the CPSR. I
need to think more about it.
> > 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.
Agreed. I just got a bit annoyed that people were trying to use the `never
break ABI' argument. We've already chosen to break the ABI in a bunch of
places, and I think that at least some of those decisions are reasonable.
Will
next prev parent reply other threads:[~2014-07-03 18:40 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-01 23:06 Android and compatibility with deprecated armv7 instructions Colin Cross
2014-07-01 23:42 ` Olof Johansson
2014-07-01 23:48 ` Mark Brown
2014-07-02 10:01 ` Will Deacon
2014-07-02 15:48 ` Colin Cross
2014-07-02 16:16 ` Will Deacon
2014-07-02 18:03 ` Christopher Covington
2014-07-02 18:25 ` Will Deacon
2014-07-02 19:47 ` Mark Brown
2014-07-05 21:26 ` Rob Herring
2014-07-02 16:39 ` Mark Brown
2014-07-02 17:01 ` Will Deacon
2014-07-02 17:33 ` Mark Brown
2014-07-02 22:14 ` Grant Likely
2014-07-03 10:41 ` Catalin Marinas
2014-07-03 14:28 ` Arnd Bergmann
2014-07-03 15:00 ` Russell King - ARM Linux
2014-07-03 15:40 ` Grant Likely
2014-07-03 17:13 ` Catalin Marinas
2014-07-03 17:48 ` Russell King - ARM Linux
2014-07-03 18:15 ` Arnd Bergmann
2014-07-03 18:30 ` Russell King - ARM Linux
2014-07-03 18:37 ` Will Deacon
2014-07-03 18:52 ` Russell King - ARM Linux
2014-07-03 19:00 ` Will Deacon
2014-07-04 8:57 ` Catalin Marinas
2014-07-04 9:25 ` Russell King - ARM Linux
2014-07-04 10:12 ` Arnd Bergmann
2014-07-04 14:09 ` Dr. David Alan Gilbert
2014-07-04 12:56 ` Grant Likely
2014-07-04 13:31 ` Russell King - ARM Linux
2014-07-03 18:46 ` Will Deacon
2014-07-03 18:53 ` Arnd Bergmann
2014-07-03 19:07 ` Russell King - ARM Linux
2014-07-03 19:40 ` Arnd Bergmann
2014-07-04 13:25 ` Grant Likely
2014-07-03 16:22 ` Grant Likely
2014-07-03 17:05 ` Russell King - ARM Linux
2014-07-03 17:32 ` Will Deacon
2014-07-03 18:23 ` Arnd Bergmann
2014-07-03 18:38 ` Peter Maydell
2014-07-03 18:40 ` Will Deacon [this message]
2014-07-03 18:32 ` Mark Brown
2014-07-03 22:16 ` Måns Rullgård
2014-07-03 22:47 ` Russell King - ARM Linux
2014-07-04 7:08 ` Ard Biesheuvel
2014-07-04 8:24 ` Catalin Marinas
2014-07-04 8:33 ` Ard Biesheuvel
2014-07-04 9:21 ` Måns Rullgård
2014-07-04 9:34 ` Russell King - ARM Linux
2014-07-04 10:21 ` Måns Rullgård
2014-07-04 10:33 ` Russell King - ARM Linux
2014-07-04 11:00 ` Ard Biesheuvel
2014-07-04 17:28 ` Nicolas Pitre
2014-07-03 17:43 ` Catalin Marinas
2014-07-04 13:22 ` Grant Likely
2014-07-04 19:24 ` Mark Brown
2014-07-04 19:33 ` Arnd Bergmann
2014-07-04 22:06 ` Måns Rullgård
2014-07-04 22:08 ` Mark Brown
2014-07-05 11:14 ` Catalin Marinas
2014-07-05 11:25 ` Russell King - ARM Linux
2014-07-05 16:43 ` Mark Brown
2014-07-05 17:06 ` Catalin Marinas
2014-07-05 18:43 ` Arnd Bergmann
2014-07-05 21:19 ` Catalin Marinas
2014-07-06 15:39 ` Arnd Bergmann
2014-07-07 13:59 ` Janne Grunau
2014-07-07 14:52 ` Catalin Marinas
2014-07-07 17:52 ` Janne Grunau
2014-07-07 15:43 ` Peter Maydell
2014-07-08 5:28 ` Måns Rullgård
2014-07-07 14:35 ` Catalin Marinas
2014-07-07 21:26 ` Arnd Bergmann
2014-07-07 12:28 ` Grant Likely
2014-07-07 18:35 ` Colin Cross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140703184017.GB21086@arm.com \
--to=will.deacon@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox