summaryrefslogtreecommitdiff
path: root/cleopatre/application/managerd/inc/managerd.h
diff options
context:
space:
mode:
Diffstat (limited to 'cleopatre/application/managerd/inc/managerd.h')
-rw-r--r--cleopatre/application/managerd/inc/managerd.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/cleopatre/application/managerd/inc/managerd.h b/cleopatre/application/managerd/inc/managerd.h
index b97a0f52d9..7e3b30ac8f 100644
--- a/cleopatre/application/managerd/inc/managerd.h
+++ b/cleopatre/application/managerd/inc/managerd.h
@@ -44,6 +44,7 @@ struct managerd_ctx {
uint8_t input_mac_addr[ETH_ALEN];
union gpio_info sc_gpio;
union gpio_info led_gpio;
+ int is_sc_available;
};
#endif /* MANAGERD_H */
determined by following pointers through the cgroup_subsys_state objects. This is because accessing the subsystem state is something that's expected to happen frequently and in performance-critical code, whereas operations that require a task's actual cgroup assignments (in particular, moving between cgroups) are less common. A linked list runs through the cg_list field of each task_struct using the css_set, anchored at css_set->tasks. - A cgroup hierarchy filesystem can be mounted for browsing and manipulation from user space. - You can list all the tasks (by pid) attached to any cgroup. The implementation of cgroups requires a few, simple hooks into the rest of the kernel, none in performance critical paths: - in init/main.c, to initialize the root cgroups and initial css_set at system boot. - in fork and exit, to attach and detach a task from its css_set. In addition a new file system, of type "cgroup" may be mounted, to enable browsing and modifying the cgroups presently known to the kernel. When mounting a cgroup hierarchy, you may specify a comma-separated list of subsystems to mount as the filesystem mount options. By default, mounting the cgroup filesystem attempts to mount a hierarchy containing all registered subsystems. If an active hierarchy with exactly the same set of subsystems already exists, it will be reused for the new mount. If no existing hierarchy matches, and any of the requested subsystems are in use in an existing hierarchy, the mount will fail with -EBUSY. Otherwise, a new hierarchy is activated, associated with the requested subsystems. It's not currently possible to bind a new subsystem to an active cgroup hierarchy, or to unbind a subsystem from an active cgroup hierarchy. This may be possible in future, but is fraught with nasty error-recovery issues. When a cgroup filesystem is unmounted, if there are any child cgroups created below the top-level cgroup, that hierarchy will remain active even though unmounted; if there are no child cgroups then the hierarchy will be deactivated. No new system calls are added for cgroups - all support for querying and modifying cgroups is via this cgroup file system. Each task under /proc has an added file named 'cgroup' displaying, for each active hierarchy, the subsystem names and the cgroup name as the path relative to the root of the cgroup file system. Each cgroup is represented by a directory in the cgroup file system containing the following files describing that cgroup: - tasks: list of tasks (by pid) attached to that cgroup - releasable flag: cgroup currently removeable? - notify_on_release flag: run the release agent on exit? - release_agent: the path to use for release notifications (this file exists in the top cgroup only) Other subsystems such as cpusets may add additional files in each cgroup dir. New cgroups are created using the mkdir system call or shell command. The properties of a cgroup, such as its flags, are modified by writing to the appropriate file in that cgroups directory, as listed above. The named hierarchical structure of nested cgroups allows partitioning a large system into nested, dynamically changeable, "soft-partitions". The attachment of each task, automatically inherited at fork by any children of that task, to a cgroup allows organizing the work load on a system into related sets of tasks. A task may be re-attached to any other cgroup, if allowed by the permissions on the necessary cgroup file system directories. When a task is moved from one cgroup to another, it gets a new css_set pointer - if there's an already existing css_set with the desired collection of cgroups then that group is reused, else a new css_set is allocated. Note that the current implementation uses a linear search to locate an appropriate existing css_set, so isn't very efficient. A future version will use a hash table for better performance. To allow access from a cgroup to the css_sets (and hence tasks) that comprise it, a set of cg_cgroup_link objects form a lattice; each cg_cgroup_link is linked into a list of cg_cgroup_links for a single cgroup on its cgrp_link_list field, and a list of cg_cgroup_links for a single css_set on its cg_link_list. Thus the set of tasks in a cgroup can be listed by iterating over each css_set that references the cgroup, and sub-iterating over each css_set's task set. The use of a Linux virtual file system (vfs) to represent the cgroup hierarchy provides for a familiar permission and name space for cgroups, with a minimum of additional kernel code. 1.4 What does notify_on_release do ? ------------------------------------ If the notify_on_release flag is enabled (1) in a cgroup, then whenever the last task in the cgroup leaves (exits or attaches to some other cgroup) and the last child cgroup of that cgroup is removed, then the kernel runs the command specified by the contents of the "release_agent" file in that hierarchy's root directory, supplying the pathname (relative to the mount point of the cgroup file system) of the abandoned cgroup. This enables automatic removal of abandoned cgroups. The default value of notify_on_release in the root cgroup at system boot is disabled (0). The default value of other cgroups at creation is the current value of their parents notify_on_release setting. The default value of a cgroup hierarchy's release_agent path is empty. 1.5 How do I use cgroups ? -------------------------- To start a new job that is to be contained within a cgroup, using the "cpuset" cgroup subsystem, the steps are something like: 1) mkdir /dev/cgroup 2) mount -t cgroup -ocpuset cpuset /dev/cgroup 3) Create the new cgroup by doing mkdir's and write's (or echo's) in the /dev/cgroup virtual file system. 4) Start a task that will be the "founding father" of the new job. 5) Attach that task to the new cgroup by writing its pid to the /dev/cgroup tasks file for that cgroup. 6) fork, exec or clone the job tasks from this founding father task. For example, the following sequence of commands will setup a cgroup named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, and then start a subshell 'sh' in that cgroup: mount -t cgroup cpuset -ocpuset /dev/cgroup cd /dev/cgroup mkdir Charlie cd Charlie /bin/echo 2-3 > cpus /bin/echo 1 > mems /bin/echo $$ > tasks sh # The subshell 'sh' is now running in cgroup Charlie # The next line should display '/Charlie' cat /proc/self/cgroup 2. Usage Examples and Syntax ============================ 2.1 Basic Usage --------------- Creating, modifying, using the cgroups can be done through the cgroup virtual filesystem. To mount a cgroup hierarchy will all available subsystems, type: # mount -t cgroup xxx /dev/cgroup The "xxx" is not interpreted by the cgroup code, but will appear in /proc/mounts so may be any useful identifying string that you like. To mount a cgroup hierarchy with just the cpuset and numtasks subsystems, type: # mount -t cgroup -o cpuset,numtasks hier1 /dev/cgroup To change the set of subsystems bound to a mounted hierarchy, just remount with different options: # mount -o remount,cpuset,ns /dev/cgroup Note that changing the set of subsystems is currently only supported when the hierarchy consists of a single (root) cgroup. Supporting the ability to arbitrarily bind/unbind subsystems from an existing cgroup hierarchy is intended to be implemented in the future. Then under /dev/cgroup you can find a tree that corresponds to the tree of the cgroups in the system. For instance, /dev/cgroup is the cgroup that holds the whole system. If you want to create a new cgroup under /dev/cgroup: # cd /dev/cgroup # mkdir my_cgroup Now you want to do something with this cgroup. # cd my_cgroup In this directory you can find several files: # ls notify_on_release releasable tasks (plus whatever files added by the attached subsystems) Now attach your shell to this cgroup: # /bin/echo $$ > tasks You can also create cgroups inside your cgroup by using mkdir in this directory. # mkdir my_sub_cs To remove a cgroup, just use rmdir: # rmdir my_sub_cs This will fail if the cgroup is in use (has cgroups inside, or has processes attached, or is held alive by other subsystem-specific reference). 2.2 Attaching processes ----------------------- # /bin/echo PID > tasks Note that it is PID, not PIDs. You can only attach ONE task at a time. If you have several tasks to attach, you have to do it one after another: # /bin/echo PID1 > tasks # /bin/echo PID2 > tasks ... # /bin/echo PIDn > tasks 3. Kernel API ============= 3.1 Overview ------------ Each kernel subsystem that wants to hook into the generic cgroup system needs to create a cgroup_subsys object. This contains various methods, which are callbacks from the cgroup system, along with a subsystem id which will be assigned by the cgroup system. Other fields in the cgroup_subsys object include: - subsys_id: a unique array index for the subsystem, indicating which entry in cgroup->subsys[] this subsystem should be managing. - name: should be initialized to a unique subsystem name. Should be no longer than MAX_CGROUP_TYPE_NAMELEN. - early_init: indicate if the subsystem needs early initialization at system boot. Each cgroup object created by