> > > 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 dr
> > > 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 dr
+christ...@brauner.io
On Sun, Oct 28, 2018 at 7:29 PM chouryzhou(周威) wrote:
...
>
> > 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 SYSVI
>> 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 pat
On Fri, Oct 26, 2018 at 2:20 AM chouryzhou(周威) wrote:
>
> 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
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" an
