> > > 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. > > Actually it is dependent on IPC_NS since it makes changes to ipc/namespace.c > which is compiled only if CONFIG_IPC_NS. >
Actually it does not require IPC_NS, the code in ipc/namespace.c are namespace specific, and is *not needed* if ipc namespace is supported. > There are a couple more implementations similar to this one. > https://lwn.net/Articles/577957/ and some submissions to AOSP derived from > that one that introduce a generic registration function for namespace support > [1], and changes to binder to implement namespaces [2]. > > If this is really needed, then we should have a solution that works for > devices without requiring IPC_NS or SYSVIPC. Also, we should not add > binder-specific code to ipc/namespace.c or include/linux/ipc_namespace.h. > > -Todd > > [1] https://android-review.googlesource.com/c/kernel/common/+/471961 > [2] https://android-review.googlesource.com/c/kernel/common/+/471825 > If the binder will be isolated by namespace, it must put binder proc and binder context in ipc_namespace (or with something like void* as [1] did) I have sent the V2 patch, that patch does not require SYSVIPC or IPC_NS. If IPC_NS is not set, binder_init will put proc and context into init_ipc_ns. If SYSVIPC and CONFIG_POSIX_MQUEUE are both unset, I will make a fake init_ipc_ns to put them. it is marked as no static intentionally to let compile generate an error if it has defined somewhere alse. The code in ipc/namespace.c is just to notify binder to do some installationwhere namespace are creating, If no IPC_NS set, the initialization in binder_init will be enough. So please review and test the V2 patch. _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
