Android and compatibility with deprecated armv7 instructions
Russell King - ARM Linux
linux at arm.linux.org.uk
Fri Jul 4 02:25:19 PDT 2014
On Fri, Jul 04, 2014 at 09:57:45AM +0100, Catalin Marinas wrote:
> On Thu, Jul 03, 2014 at 07:30:55PM +0100, Russell King - ARM Linux wrote:
> > Even with SWP_EMULATE enabled and with the debug problem fixed... does
> > it help warn people? Only if you're running on a CPU with virtualisation
> > extensions, because it silently continues to work on CPUs without.
>
> Some clarification here. The virtualisation extensions made SWP
> _optional_ (i.e. it may not be present at all). The ARMv7
> multiprocessing extensions introduced the possibility to disable/trap
> SWP via the SCTLR.SW bit because it was no longer atomic. So basically
> native SWP only works (as expected, atomically) on ARMv7 UP and earlier.
Yes, but we've cocked this up - on ARMv7 SMP, we don't force SWP to be
enabled. So, you may have SWP in hardware, which may not be atomic,
but as everyone seems to have SWP_EMULATE /disabled/ we don't know
whether the instruction even exists in any programs or libraries.
It may be that it's been completely eliminated, but we don't know that,
because we've never had the trapping enabled for SMP systems.
On the flip side (as I mentioned to Will) I don't think the situation is
quite as serious as Grant makes it out to be for Android.
There, the user base is already used to apps which don't work with new
Android devices. For example, despite Android scaling the graphics to
the screen size, there are apps that don't work merely because the screen
is bigger, and the play store knows this and doesn't offer them. However,
it /is/ still possible to install them (and some people have) by
downloading the .apk file and putting that on SD card. In this case,
the app (a game) worked perfectly except that the game controls were at
an absolute screen position rather than a scaled position, which is why
the game was no longer offered for the later devices.
Moreover, when you download from the play store, you are only presented
with the version which is appropriate for your device - when you buy a
new device, and you re-fetch your apps, you don't get the same version
that you've had on previous device if there's one more appropriate for
your new device.
So the Linux userspace policy doesn't really apply all that much to the
Android space - I'm not saying we shouldn't try, I'm saying that users
are already used to their apps not working on new devices for a wide
variety of reasons.
The "this app starts unexpectedly crashing (due to swp) when I install
it on a new device" shouldn't happen because they shouldn't be presented
with the app in the first place.
At least this is what I've been told by an experienced Android user and
support person (who does do things like install from .apk's...)
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
More information about the linux-arm-kernel
mailing list