[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47B953A8.9030206@cn.fujitsu.com>
Date: Mon, 18 Feb 2008 17:45:12 +0800
From: Li Zefan <lizf@...fujitsu.com>
To: Paul Menage <menage@...gle.com>
CC: balbir@...ux.vnet.ibm.com, balbir@...ibm.com, pj@....com,
Pavel Emelianov <xemul@...nvz.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
vatsa@...ux.vnet.ibm.com, akpm@...ux-foundation.org,
containers@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 1/7] CGroup API: Add cgroup.api control file
Paul Menage wrote:
> On Feb 16, 2008 2:07 AM, Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:
>> Paul Menage wrote:
>>
>> Hi, Paul,
>>
>> Do we need to use a cgroup.api file? Why not keep up to date documentation and
>> get users to use that. I fear that, cgroup.api will not be kept up-to-date,
>> leading to confusion.
>
> The cgroup.api file isn't meant to give complete documentation for a
> control file, simply a brief indication of its usage.
>
But we don't have /proc/proc.api or /sys/sysfs.api ...
> The aim is that most bits of the information reported in cgroup.api
> are auto-generated, so there shouldn't be problems with it getting
> out-of-date.
>
> Is it just the space used by the documentation string that you're
> objecting to? The other function of the file is to declare a type for
> each variable.
>
[root@...alhost mnt]# cat cgroup.api
debug.current_css_set_refcount u64
debug.current_css_set u64
debug.taskcount u64
debug.cgroup_refcount u64
cgroup.release_agent string Path to release agent binary
cgroup.api unknown Control file descriptions
cgroup.releasable u64 Is this cgroup able to be freed when empty
cgroup.notify_on_release u64 Should the release agent trigger when this cgroup is empty
cgroup.tasks string Thread ids of threads in this cgroup
It seems to me this is a little messy.
And is it better to describe the debug subsystem too?
--
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