Quoting Tejun Heo (tj@xxxxxxxxxx): > A bit of addition. > > On Tue, Apr 09, 2013 at 12:38:51PM -0700, Tejun Heo wrote: > > > We need to make the distribute approach work in order to support > > > containers, which requiring them to have a back-channel open to > > > the host userspace. If we can do that, then we've solved the problem > > Why is back-channel such a bad thing? Even fully virtualized > environments do special things to communicate with the host (the whole > stack of virt drivers). It is sub-optimal and pointless to make > everything completely transparent. There's nothing wrong with the > basesystem knowing that they're inside a container or a virtualized > environment, so I don't understand why a back-channel is such a big > problem. Agreed, that's fine so long as it will be a consistent interface. Ideally, we could do it in a way that the container monitor can transparently proxy between userspace inside the container and the library on the host - so that userspace can 'use cgroups' the same way no matter where it is. So for instance if there is a dbus call saying "please create cgroup /x with (some constraints) and put $$ into it", "something" in the container can convert that into "please create cgroup /lxc/c1/x and put (host_uid($$)) into it" and pass that to the host's (or parent container's) "something". So perhaps it is best if the container monitor, living in the parent namespaces, opens a socket '@cgroup_monitor' in the container namespace (through setns), listens for container-userpsace requests there, and passes them on to the host's monitor (which hopefully also listens on '@cgroup_monitor', @ being '\0'). Note that my mentino of converting pids requires a new kernel feature which we don't currently have (but have wanted for a long time). -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
