>> 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 <chouryz...@tencent.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. _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
