[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <5FBCBE569E134E4CA167B91C0A77FD610198F6B4F6@EXMBX-SZMAIL022.tencent.com>
Date: Mon, 29 Oct 2018 02:29:08 +0000
From: chouryzhou(周威) <chouryzhou@...cent.com>
To: Todd Kjos <tkjos@...gle.com>
CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Arve Hjønnevåg <arve@...roid.com>,
Todd Kjos <tkjos@...roid.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"dave@...olabs.net" <dave@...olabs.net>,
"open list:ANDROID DRIVERS" <devel@...verdev.osuosl.org>,
LKML <linux-kernel@...r.kernel.org>,
chouryzhou(周威) <chouryzhou@...cent.com>
Subject: RE: [PATCH] binder: ipc namespace support for android binder
>> Hi
>> We are working for running android in container, but we found that binder is
>> not isolated by ipc namespace. Since binder is a form of IPC and therefore should
>> be tied to ipc namespace. With this patch, we can run more than one android
>> container on one host.
>> This patch move "binder_procs" and "binder_context" into ipc_namespace,
>> driver will find the context from it when opening. Althought statistics in debugfs
>> remain global.
>>
>> Signed-off-by: choury zhou <chouryzhou@...cent.com>
>> ---
>> drivers/android/Kconfig | 2 +-
>> drivers/android/binder.c | 126 +++++++++++++++++++++++++---------
>> include/linux/ipc_namespace.h | 14 ++++
>> ipc/namespace.c | 4 ++
>> 4 files changed, 111 insertions(+), 35 deletions(-)
>>
>> diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
>> index 432e9ad77070..09883443b2da 100644
>> --- a/drivers/android/Kconfig
>> +++ b/drivers/android/Kconfig
>> @@ -10,7 +10,7 @@ if ANDROID
>>
>> config ANDROID_BINDER_IPC
>> bool "Android Binder IPC Driver"
>> - depends on MMU
>> + depends on MMU && SYSVIPC
>
> NAK. We can't force SYSVIPC on for Android. The notion of running
> binder in a container is reasonable, but needs to be done without
> explicit requirement for SYSVIPC. binder-in-container is a topic in
> the android microconf at Linux plumbers -- are you going to be at LPC?
>
We have no plan to going to attend LPC temporarily.
> It's not obvious from this patch where this dependency comes
> from...why is SYSVIPC required? I'd like to not have to require IPC_NS
> either for devices.
Yes, the patch is not highly dependent on SYSVIPC, but it will be convenient
if require it. I will update it to drop dependency of it in V2 patch. This patch
doesn't need IPC_NS set at present.
Powered by blists - more mailing lists