On 09/07/2010 10:26 PM, Paul Menage wrote: > On Tue, Sep 7, 2010 at 1:23 PM, Daniel Lezcano<daniel.lezcano@xxxxxxx> wrote: > >>> This bit is awkward - you're storing the original value of the >>> clone_children flag to report in the mount options, but this isn't >>> necessarily the current state. Might it be better to not store this >>> and just report the current value of the root cgroup's >>> CGRP_CLONE_CHILDREN flag? >>> >>> >> Sure. Shall I do the same as the release agent mount option ? >> > I think so - the slight problem with this new flag is that it's > possible for the root cgroup to have one setting for clone_children > and all its children to have a different setting. But I guess we can > live with that. (Or maybe simply not make the default clone_children > value a mount option, but require it to be set on the root cgroup > after mounting?) > The clone_children option behaves like the release-agent mount option no ? We can mount with a specific release agent and change it at runtime. IMHO it would be better to give a chance to the administrator to set its system with the mount option instead of force him to write post mount scripts. An alternative would be to set this cgroup option *only* via the mount option, but I am not sure it is good as it may be an unresolvable constraint for a system wanting to use the cgroups with and without this option (same kind of constraint we have with the ns_cgroup). I am favorable to keep the mount option and the ability to change it for another cgroup. -- Daniel _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers