Android and compatibility with deprecated armv7 instructions

[catalin.marinas@arm.com (Catalin Marinas)]

(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:
> On Wed, Jul 2, 2014 at 6:01 PM, Will Deacon <will.deacon@arm.com> wrote:
> > On Wed, Jul 02, 2014 at 05:39:23PM +0100, Mark Brown wrote:
> >> On Wed, Jul 02, 2014 at 11:01:33AM +0100, Will Deacon wrote:
> >>
> >> >   (1) The hardware doesn't have the instruction at all. If we start
> >> >       emulating it, then we'll always have to emulate it and it doesn't
> >> >       encourage software migration.
> >>
> >> That's what the logging other architectures did in similar situations
> >> was intended to help address - even if people don't care about the
> >> performance impact having loud complaints in the logs tends to cause
> >> some useful subset of users to report it as a problem.
> >
> > I don't think logging something to dmesg is going to make a blind bit of
> > difference on an Android device. Maybe we could get SWP emulation to request
> > access to the users contacts and send everybody a text message each time
> > they issue the instruction?
> >
> > Seriously though, nothing causes loud complaints like a SIGILL. This thread
> > is evidence of that.
> 
> I think that looks at the problem entirely the wrong way around. We
> don't break userspace. That's been a rule for a very long time.

In my view, we don't break user space. It's rather a choice of how much
legacy we support on ARMv8 hardware with an arm64 kernel. We don't even
provide HWCAP_SWP for compat (not that anyone bothers checking that).
It's a similar reason we choose not to support/emulate NWFPE or OABI
even though there are existing binaries out there. If we choose to
support SWP in the arm64 kernel, then we won't be able to break user
space and have to carry it for a long time (unless you figure out a way
to remove such features from the kernel because HWCAP certainly doesn't
work, nor printk).

The ARM feature deprecation/removal cycle allows for two architecture
revisions before being entirely removed. SWP has been deprecated in
ARMv6, made optional in ARMv7 (with the possibility of disabling it if
still available) and removed in ARMv8. The Thumb-1/2 instruction sets
never had the SWP instruction. Even when SWP was available in certain
ARMv7 implementations, it was no longer guaranteed to be atomic.

> 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_.

Note that I don't say Google should break those applications but they
can carry a patch in their Android kernel while reaching out to
developers to sort their code (can the Android app store be scanned?).
What I don't want is to be in a situation 10 years from now when we
still carry SWP emulation code that no-one uses but we can't remove
because it would break the user space features we agreed upon.

I have limited knowledge of Android user space but I think SWP emulation
could also be implemented in user space via a SIGILL handler in the
zygote thread and inherited by forked apps (performance doesn't really
matter here). A similar example for Android is the binder driver
user-kernel ABI. AFAIK, Google decided not to provide a compat ABI for
the 64-bit compilation of this driver but update the AArch32 user-space
library to use the new 64-bit ABI. That's perfectly fine by me, they
chose not to provide such ABI in the kernel but solve it entirely in
user space and could do the same with SWP.

-- 
Catalin