Messages in this thread | | | Date | Tue, 9 Apr 2013 16:04:22 -0500 | From | Serge Hallyn <> | Subject | Re: cgroup: status-quo and userland efforts |
| |
Quoting Tejun Heo (tj@kernel.org): > 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
| |