On Wed, 2018-06-13 at 13:23 +0200, Adam Borowski wrote:
> Hi Ben!
> Could you please chime in to bug #901134 (RFS: anbox-modules)?
>
> This package wants to ship redundant copies of two modules (ashmem and
> binder) that are already in mainline since a long time ago. This strikes me
> as thoroughly wrong, yet I'm very ignorant about packaged kernels, thus I
> can't offer good advice.
I agree, I don't think it makes much sense to build these OOT if they
can be built in-tree.
The in-tree version of ashmem *cannot* be built as a module, though,
which we would probably want to change.
[...]
> Indeed, these two modules are not built within Debian kernels. They depend
> on CONFIG_ANDROID, which doesn't look like it does anything anymore except
> allowing to enable these two modules. I have bad memories of Android
> kernels doing some very naughty things (magic hard-coded uids/gids, etc),
> but I don't know if that was related to CONFIG_ANDROID or not. Even if it
> was in the past, it seems that in mainline that setting is safe to enable.
>
> But, all of this lies in Ben's kingdom, of which I'm not knowledgeable
> enough. Thus, some advice would be nice.
I do wonder what the value of enabling these as in-tree modules would
be. I don't think we package the many Android userspace services and
libraries that would be needed to run Android apps. So how would these
modules be useful? Is the idea to support running an Android system in
a container?
Ben.
--
Ben Hutchings
The most exhausting thing in life is being insincere.
- Anne Morrow Lindberg
Attachment:
signature.asc
Description: This is a digitally signed message part