Re: [lxc-devel] RFC: Device Namespaces

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

Jeremy Andrus <jeremya-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> writes:

> On Sep 25, 2013, at 4:23 PM, Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>
>> Janne Karhunen <janne.karhunen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>> 
>>> That being said, is there a valid reason why binder is part of device
>>> namespace here instead of IPC?
>> 
>> I think the practical issue with binder was simply that binder only
>> allows for a single instance and thus is does not play nicely with
>> containers.
>
> It's true that there was a singleton paradigm in binder that had to be
> overcome, but I agree with Janne. It really belongs in the IPC namespace,
> and I don't see any technical reason not to move it there.

*Blink* I missed the IPC namespace suggestion.

The IPC namespace sounds reasonable.

Of course binder is still in staging because it has implementation and
ABI problems.  Little things like a 64bit kernel and a 32bit userspace
don't work particularly well.  So while fixing those problems it might
be possible to fix the single container problem as well.  It would be a
weird direction for cleanup of binder to come from but I don't see why
that wouldn't work.

Personally until binder is out of staging it seems reasonable to push
for an API that sucks less, or for a more general solution that Androdid
could use instead of binder.

One of the uses of namespaces is to clean up after problematic kernel
design decisions.  If we still have the option I would rather fix the
problems than clean up after them.

Eric