On Thu, Sep 26, 2013 at 12:47 AM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx>wrote: > Jeremy Andrus <jeremya@xxxxxxxxxxxxxxx> writes: > > > On Sep 25, 2013, at 4:23 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> > wrote: > > > >> Janne Karhunen <janne.karhunen@xxxxxxxxx> 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. > Binder rewrite for IPC namespace is in the works (by Oren) We discussed this with Greg and adding namespace support to binder (in staging) seemed reasonable to him as well. > 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 > > _______________________________________________ > Containers mailing list > Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linuxfoundation.org/mailman/listinfo/containers > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
