From: Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org>
To: Paul Menage <menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: "Serge E. Hallyn"
<serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
"Eric W. Biederman"
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Subject: Re: [PATCH 1/3] cgroup : add clone_children control file
Date: Tue, 07 Sep 2010 23:13:05 +0200 [thread overview]
Message-ID: <4C86AAE1.2030608@free.fr> (raw)
In-Reply-To: <AANLkTi=zsT4=YZgpu5x9xtgskoTCjgTq+Vt6wh-8QtB=@mail.gmail.com>
On 09/07/2010 10:26 PM, Paul Menage wrote:
> On Tue, Sep 7, 2010 at 1:23 PM, Daniel Lezcano<daniel.lezcano-GANU6spQydw@public.gmane.org> 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
next prev parent reply other threads:[~2010-09-07 21:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-04 7:31 [PATCH 1/3] cgroup : add clone_children control file Daniel Lezcano
[not found] ` <1283585466-30265-1-git-send-email-daniel.lezcano-GANU6spQydw@public.gmane.org>
2010-09-04 7:31 ` [PATCH 2/3] cgroup : make the mount options parsing more accurate Daniel Lezcano
[not found] ` <1283585466-30265-2-git-send-email-daniel.lezcano-GANU6spQydw@public.gmane.org>
2010-09-07 19:38 ` Paul Menage
[not found] ` <AANLkTi=2qWKXGBsqmbZjUs_H2VSDykheAABha079puT3-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-09-07 20:24 ` Daniel Lezcano
2010-09-04 7:31 ` [PATCH 3/3] cgroup : remove the ns_cgroup Daniel Lezcano
2010-09-07 19:34 ` [PATCH 1/3] cgroup : add clone_children control file Paul Menage
[not found] ` <AANLkTi=hM66-F-U2-ZoiDgksh51hq3MLb5aSLmwsShwi-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-09-07 20:23 ` Daniel Lezcano
[not found] ` <4C869F48.9050603-GANU6spQydw@public.gmane.org>
2010-09-07 20:26 ` Paul Menage
2010-09-07 21:13 ` Daniel Lezcano [this message]
[not found] ` <4C86AAE1.2030608-GANU6spQydw@public.gmane.org>
2010-09-07 21:22 ` Paul Menage
[not found] ` <AANLkTik+wrNXZtcD_0OcGQUtcZbu7SVNUUaTKHqTBf8m-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-09-07 23:35 ` Daniel Lezcano
-- strict thread matches above, loose matches on Subject: below --
2010-07-29 19:56 Serge E. Hallyn
[not found] ` <20100729195629.GA13378-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
2010-08-03 8:30 ` Li Zefan
2010-08-03 8:30 ` Li Zefan
2010-07-29 19:56 Serge E. Hallyn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C86AAE1.2030608@free.fr \
--to=daniel.lezcano-ganu6spqydw@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
--cc=menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.