On Fri, Sep 22, 2017 at 9:00 AM, Martijn Coenen <maco@xxxxxxxxxxx> wrote:
>> The case that gets interesting is a any kind of user that wants to
>> run an Android application on a regular Linux box without
>> using virtual machines or emulation, e.g. a an app developer,
>> or a user that wants to run some Android app on their desktop
>> using anbox.
>
> I don't think the binder driver is present on any regular Linux box,
> so things like anbox actually have to provide it as a module. It looks
> like the current version of anbox is actually using the v8 interface,
> and is also using a modified version of the binder driver (eg for
> dkms, but also other hacks). The other popular one is Shashlik, but
> looks like it uses a VM (just for binder). The v7 interface doesn't
> work on 64-bit machines at all, so any container userspace using v7
> would be seriously limiting the number of machines it could be run on,
> whereas v8 runs on both 32 and 64. So I'm not sure we have to be
> concerned about things like this, certainly if we have communicated
> earlier (as Greg said) that binder shouldn't be used outside Android
> pre 4.14.
Ok.
>> The scenario I had in mind is like this:
>
> Thanks for clarifying! I think this works, but it's additional code to
> maintain and support for a pretty rare (and unsupported?) scenario. I
> understand that hiding ABI behind a config option is not a good
> design, and that it must be removed. If we really can't remove v7 from
> 4.14, I would actually prefer to leave the config option (but flip the
> default to v8), and remove it as soon as we think it can be (eg once P
> has been in the field for a while).
How would waiting help?
If we are reasonably sure that it's not a problem, then let's remove
the v7 support now and see if anyone complains (and put it back
if they did have a reason to need it).
If we can assume that the upstream binder driver (unlike
third-party modules for anbox, which are not affected as you
say) is only ever used with a platform specific full Android
build, the question is what upgrade scenarios a device might
need to support.
The relevant cases would seem to be:
1. updating a 32-bit Android Oreo (or earlier) OS from linux-4.9
(or earlier) to linux-4.14 (or later) without updating libbinder:
This would require keeping around compile-time option
at least, for as long new kernels are supported on Oreo.
2. updating a 32-bit kernel to a 64-bit kernel on hardware
that allows this, without changing anything else:
Theoretically fixable, but this would require significant
code changes in the kernel module, similar to what I
described above.
3. upgrading from Android Oreo (or earlier) to Android P
while upgrading the kernel at the same time: should
be no problem.
4. upgrading from Android Oreo (or earlier) to Android P
libbinder without upgrading the kernel: this might
require patching the old kernels to enable the v8 ABI.
Not our problem here, as it only concerns older kernels.
What assumptions can we make about the two problematic
cases (1 and 2) here? Is it reasonable to require device
makes to always update libbinder together with the kernel?
Could that run into problems after a botched upgrade that
reverts back to an older kernel but keeps the new user space
or vice versa?
Arnd
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
