RE: [PATCH] binder: ipc namespace support for android binder

[chouryzhou(åå)]

>> 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@xxxxxxxxxxx>
>> ---
>>  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.