summaryrefslogtreecommitdiffstats
path: root/src/libcgroup.map
Commit message (Collapse)AuthorAgeFilesLines
* api for generating the list of variables of given controllerIvana Hutarova Varekova2010-02-101-0/+2
| | | | | | | | | | | | | | | api for generating the list of variables of given controller: changelog - v2: fixed the space on the end of lines * int cgroup_get_value_name_count(struct cgroup_controller, *controller) functions return the number of variables in "controller" * char *cgroup_get_value_name(struct cgroup_controller *controller, int index) function return the "index" variable of "controller" Signed-off-by: Ivana Hutarova Varekova <varekova@redhat.com> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
* add api for generating the list of all controllers (not only mount ones)Ivana Hutarova Varekova2009-08-061-0/+3
| | | | | | | | | | | | | | | | | | | | | | this patch add api for generating the list of all controllers (not only mount ones) - it uses three functions: cgroup_get_all_controller_begin cgroup_get_all_controller_next cgroup_get_all_controller_end and structure: struct controller_data { char name[FILENAME_MAX]; int hierarchy; int num_cgroups; int enabled; }; the data are read from /proc/cgroups file Signed-off-by: Ivana Hutarova Varekova <varekova@redhat.com> Reviewed-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
* Add recursive cgroup_delete_cgroup_ext.Jan Safranek2009-08-061-0/+1
| | | | | | | | | | | | | | | | | | | Changelog: - add braces to cgroup_delete_cgroup_ext to improve readability - use enum instead of macro to define flags The new function allows to recursively delete whole tree of groups. There is new infrastructure created around (cg_delete_cgroup_controller_recursive). It has inconsistent behavior when root group removal is requested - it removes all children (if requested), but does not remove the root itself and returns success value. This allows simple rewrite of cgclear functions to use this function. Original cgroup_delete_cgroup now leads to cgroup_delete_cgroup_ext. Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
* removes copy_name_value_from_rules to wrapperIvana Varekova2009-08-061-0/+5
| | | | | | | | | move copy_name_value_from_rules procedure to wrapper.c file and add the header to libcgroup-internal.h Signed-off-by: Ivana Varekova <varekova@redhat.com> Acked-by: Dhaval Giani <dhaval@linux.vnet.ibm.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
* Add the library function cgroup_register_unchanged_process().Ken'ichi Ohmichi2009-06-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hi, Changelog of v6: ================ * No change. Changelog of v5: ================ * Rebase the patch to the latest code. Changelog of v4: ================ * No change. Changelog of v3: ================ * No change. Changelog of v2: ================ * New patch. Description: ============ This patch adds the library function cgroup_register_unchanged_process() for notifying cgrulesengd daemon of the unchanged process. Thanks Ken'ichi Ohmichi Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
* Add the key "process name" to find a matching rule.Ken'ichi Ohmichi2009-06-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hi, Changelog of v6: ================ * No change. Changelog of v5.1: ================== * BUGFIX: Clear the flags meaning "found a matching rule" when a process name does not match. There was a problem that cgexec and cgclassify didn't work correctly if a user executes cgexec/cgclassify based on /etc/cgrules.conf. For example, if a root user executes `cgclassify $$` on the following /etc/cgrules.conf, the process ($$) should be moved to users/root on cpuset and memory subsystems. But the process was moved to users/root/cp on memory subsystem only. Example of /etc/cgrules.conf: ============================= root:cp cpuset users/root/cp % memory users/root/cp root cpuset users/root % memory users/root The cause is why the flags meaning "found a matching rule" (uid, gid, and matched) is not cleared when a process name does not match. This problem is fixed on this patch. Changelog of v5: ================ * Rebase the patch to the latest code. Changelog of v4: ================ * No change. Changelog of v3: ================ * BUGFIX: Fix the handling of '%' in /etc/cgrules.conf. Changelog of v2: ================ * Use strcmp() instead of strncmp() for checking a process name strictly. * Some cleanups. Description: ============ This patch adds the key "process name" to find a matching rule. Thanks Ken'ichi Ohmichi Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
* Add cgroup_get_procname_from_procfs() for getting a process name.Ken'ichi Ohmichi2009-06-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hi, Changelog of v6: ================ * Change the returning values of *_get_procname_from_proc*() to integer from charactor pointer. * Clarify the number meaning of string length in cg_get_procname_from_ ~proc_status() Changelog of v5: ================ * Rebase the patch to the latest code. Changelog of v4: ================ * Add the error handling for strdup()'s error. * Reduce strlen() calls. * Make the check code of a process name simple. Changelog of v3: ================ * Move cgroup_get_procname_from_procfs() to libcgroup-internal.h. * Fix unclear buffer of buf_cwd by memset(). * Get a real path of script file by realpath(). Changelog of v2: ================ * It is possible to handle a process, which name length is over than 16 characters, also. Description: ============ This patch adds a new function cgroup_get_procname_from_procfs() for getting a process name. This function allocates the memory for a process name, and writes the name to the memory, and returns the pointer of the memory. So a caller should free the memory if unusing it. The process name, which is wrotten by this function, depends on the specified process: If a command process) the full path of command. If a shell script process) the full path of shell script. If a kernel thread) the process name of kernel thread. Thanks Ken'ichi Ohmichi Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
* libcgroup: Introduce an API to get the mount point of a specific subsystemDhaval Giani2009-06-261-0/+1
| | | | | | | | | Introduce an API which will query the mount table and return the mount point of a specific subsystem. This is needed in the case when the user knows which subsystem he wants the details of, which would make the use of the get_controller* APIs cumbersome. Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
* libcgroup: Introduce a unload cgroups APIDhaval Giani2009-06-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This API will unload the cgroups created in the cgroupfs and unmount and delete the filesystem mount point. The action is equivalent to what is done currently in service cgconfig stop. The reason for this API is to make sure we don't end up with a asymmetric library API subset. Today an application program can programatically through cgroup_config_load_config() load a configuration file, but has no means to cleanup (including all temporarily created groups). changes from v3 1. Address Jan's comments from http://article.gmane.org/gmane.comp.lib.libcg.devel/1105 changes from v2 1. Fix a leak as noted by Bharata 2. Address Balbir's review comments at http://article.gmane.org/gmane.comp.lib.libcg.devel/1080 changes from v1 1. Change the name of the function to cgroup_unload_cgroups 2. Change the name of the executatble to cgclear 3. Split out the funtions Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com> Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>
* libcgroup: Introduce get_controller APIDhaval Giani2009-06-181-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | This set of APIs will allow the caller to query the mount table and find out what controller is mounted at what path. Test program has been included in the patch. Running the test program results in [dhaval@gondor tests]$ ../libtool --mode=execute ./get_controller Controller cpu is mounted at /cgroup Controller cpuacct is mounted at /cgroup Controller memory is mounted at /cgroup1 [dhaval@gondor tests]$ Which is the setup on this system. Changes from v2 1. Remove the incorrect comments as pointed out by Bharata Changes from v1 1. Use a new structure as mentioned by bharata to return the values. Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com> Cc: Jan Safranek <jsafrane@redhat.com> Acked-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
* libcgroup: Introduce post order walkDhaval Giani2009-06-181-0/+1
| | | | | | | | | | With the introduction of the flags, we now actually make use of them. This patch adds a post mode and modifies the test case to also do a post order walk. Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com> Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com> Acked-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
* Cleanup: Integrate similar code to cgroup_get_uid_gid_from_procfs().Ken'ichi Ohmichi2009-06-081-0/+1
| | | | | | | | | | | | | | CHANGELOG of v2.1: ================ * Rebase the patch for commit '340feae163c4797a6cb1247b3812c1ccdc52fa41'. There are some similar functions for getting process's data (uid, gid) from /proc/<pid>/status file, so this patch integrates these functions into one cgroup_get_uid_gid_from_procfs(). Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp> Reviewed-By: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
* libcgroup: Export cgroup_get_controller APIDhaval Giani2009-06-031-0/+1
| | | | | | | | | libcgroup: Export cgroup_get_controller API This wrapper was not exposed for some reason earlier. Make it available from the library. Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
* libcgroup: Correct the version to which the statistics API belongDhaval Giani2009-04-221-3/+3
| | | | | | | These APIs were not available in v0.33. They will be a part of v0.34 however. Make the change in libcgroup.map reflecting this. Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
* libcgroup: Add new API to walk tasksDhaval Giani2009-04-221-0/+6
| | | | | | | | | Add a new API to iterate through the tasks file to get the list of all the tasks in a cgroup. Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com> Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com> Acked-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
* Here is the v2 of the patch which introduces APIs to read controllerBharata B Rao2009-04-011-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | specific stats. Added Makefile.am updates which I had missed in the previous post. New APIs to read controller specific statistics. This patch introduces 3 new APIs which can be used to read controller statistics iteratively. (Eg. stats from memory.stat etc) Reading of stats is initiated by cgroup_read_stats_begin() API, which returns the first stat of the requested controller in addition to returing a handle that should be used in subsequent reads. cgroup_read_stats_next() API can be used to read the remaining stats one by one. This needs the handle returned by cgroup_read_stats_begin(). cgroup_read_stats_end() API will terminate the stats reading iteration initiated by cgroup_read_stats_begin(). Changelog: v2 - Update tests/Makefile.am so that it generates appropriate rules for tests/read_stats.c in the Makefile. This is in addition to the manual updates done to the generated file tests/Makefile.in. v1 - cgroup_read_stats apis now work with relative cgroup path names instead of absolute path names. v0 - Initial post. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
* Distribute files to various subdirectoriesJan Safranek2009-03-261-0/+56
Signed-off-by: Jan Safranek <jsafrane@redhat.com>