[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAB0TPYEU8w8PzqYjeoAX=LvMabeHR7Zw4u8NscUGf=+rw96cag@mail.gmail.com>
Date: Fri, 22 Sep 2017 09:00:46 +0200
From: Martijn Coenen <maco@...roid.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Christoph Hellwig <hch@...radead.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Arve Hjønnevåg <arve@...roid.com>,
Riley Andrews <riandrews@...roid.com>,
devel@...verdev.osuosl.org, Todd Kjos <tkjos@...roid.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
John Stultz <john.stultz@...aro.org>
Subject: Re: [PATCH] android: binder: fix type mismatch warning
On Wed, Sep 20, 2017 at 3:37 PM, Arnd Bergmann <arnd@...db.de> wrote:
> I'm not really worried about shipping Android products, for those
> there is no big problem using the compile-time option as they build
> everything together.
Ack.
> 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.
> 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).
Thanks,
Martijn
Powered by blists - more mailing lists