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. 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
