Re: [PATCH] cgroup : remove the ns_cgroup

[Daniel Lezcano <daniel.lezcano@free.fr>]

On 01/27/2011 02:45 AM, Andrew Morton wrote:
> On Thu, 27 Jan 2011 09:08:51 +0800 Li Zefan<lizf@cn.fujitsu.com>  wrote:
>
>> Andrew Morton wrote:
>>> On Tue, 25 Jan 2011 10:39:48 +0100
>>> Daniel Lezcano<daniel.lezcano@free.fr>  wrote:
>>>
>>>> This patch removes the ns_cgroup as suggested in the following thread:
>>> I had this patch queued up in September last year, but dropped it.  Why
>>> did I do that?
>> Because you wanted to wait for some time for users (if any) to notice this
>> coming change.
>>
>> Author: Daniel Lezcano<daniel.lezcano@free.fr>
>> Date:   Wed Oct 27 15:33:38 2010 -0700
>>
>>      cgroup: notify ns_cgroup deprecated
>>
>>      The ns_cgroup will be removed very soon.  Let's warn, for this version,
>>      ns_cgroup is deprecated.
>>
>>      Make ns_cgroup and clone_children exclusive.  If the clone_children is set
>>      and the ns_cgroup is mounted, let's fail with EINVAL when the ns_cgroup
>>      subsys is created (a printk will help the user to understand why the
>>      creation fails).
>>
>>      Update the feature remove schedule file with the deprecated ns_cgroup.
>>
>>      Signed-off-by: Daniel Lezcano<daniel.lezcano@free.fr>
>>      Acked-by: Paul Menage<menage@google.com>
>>      Signed-off-by: Andrew Morton<akpm@linux-foundation.org>
>>      Signed-off-by: Linus Torvalds<torvalds@linux-foundation.org>
> ooh, that was clever of me.
>
> Here is the text which was missing from the changelog:
>
>    This is a userspace-visible change.  Commit 45531757b45c ("cgroup:
>    notify ns_cgroup deprecated") (merged into 2.6.27) caused the kernel
>    to emit a printk warning users that the feature is planned for
>    removal.  Since that time we have heard from XXX users who were
>    affected by this.
>
> Please provide XXX.

Ok, AFAIK nobody makes use of the ns_cgroup except the LXC userspace 
tools which I maintain and where
the backward compatibility with the ns_cgroup and the clone_children 
flag is already implemented.
Since today nobody seems to be affected by this.

I Cc'ed the libvirt mailing list.

> How do we know that 2.6.37->2.6.38 is long enough?  Will any major
> distros be released containing this warning in that timeframe?  I doubt
> it.

Hmm, maybe it is too short but I don't think someone will complain about 
this feature removal.
Google chromium is using the namespaces, hence a lot of cgroup is 
created on the system. The vsftpd and some pam modules uses the 
namespaces too.
I won't be surprised if one of these applications fails with 'clone' 
returning EEXIST ...