[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4EFAB2E2.4040008@cn.fujitsu.com>
Date: Wed, 28 Dec 2011 14:10:42 +0800
From: Li Zefan <lizf@...fujitsu.com>
To: Tejun Heo <tj@...nel.org>
CC: LKML <linux-kernel@...r.kernel.org>,
Cgroups <cgroups@...r.kernel.org>
Subject: Re: [PATCH] cgroup: fix to allow mounting a hierarchy by name
Tejun Heo wrote:
> Hello, Li.
>
> On Tue, Dec 27, 2011 at 10:10:37AM +0800, Li Zefan wrote:
>> If we mount a hierarchy with a name specified, the name is unique,
>> and we can use it to mount the hierarchy without specifying its
>> set of subsystem names. This feature is documented is
>> Documentation/cgroups/cgroups.txt section 2.3
>>
>> Here's an example:
>>
>> # mount -t cgroup -o cpuset,name=myhier xxx /cgroup1
>> # mount -t cgroup -o name=myhier xxx /cgroup2
>>
>> But it was broken by commit 32a8cf235e2f192eb002755076994525cdbaa35a
>> (cgroup: make the mount options parsing more accurate)
>>
>> This fixes the regression.
>
> Hmmm... so that has been broken over a year and nobody complained? Is
> there any valid use case where specifying mount path as all other
> filesystems wouldn't work? Is this 'name' thing necessary at all?
> Maybe we should rip it out instead of fixing it? We can just leave it
> as non-functional name which does nothing but being visible in mount
> listing.
>
The "name" option was introduced along with the "none" option, so we
can distinguish between different cgroup hierarchies which have no
bound subsystems, like this:
# mount -t cgroup -o none,name=hier1 xxx /cgroup1
# mount -t cgroup -o none,name=hier2 xxx /cgroup2
As the name is unique, we have this "mount by hierarchy name" feature.
It looks reasonable, but I guess few people know this feature. We can
live with it, as it only saves us some typing when mounting an existing
hierarchy. On the other hand, removing this small feature can hardly
result in code reduction.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists