lkml.org 
[lkml]   [2008]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 1/7] CGroup API: Add cgroup.api control file
Paul Menage wrote:
> On Feb 16, 2008 2:07 AM, Balbir Singh <balbir@linux.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@localhost 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?



\
 
 \ /
  Last update: 2008-02-18 10:49    [W:0.058 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site