...
sleepVm(string vm_name) | Puts the named VM to sleep. |
resumeVm(string vm_name) | Resumes the named VM from sleep. |
pauseVm(string vm_name) | Pauses the named VM. |
unpauseVm(string vm_name) | Unpauses the named VM. |
rebootVm(string vm_name) | Reboots the named VM. |
shutdownVm(string vm_name) | Shuts down the named VM. |
startVm(string vm_name) | Starts the named VM. |
suspendVmToFile(string vm_name, string filename) | Suspends the named VM to the specified file. |
resumeVmFromFile(string vm_name, string filename) | Resumes the named VM from the specified file. |
sleepVmUuid(string vm_uuid) | Puts the VM with the specified UUID to sleep. |
resumeVmUuid(string vm_uuid) | Resumes the VM with the specified UUID from sleep. |
pauseVmUuid(string vm_uuid) | Pauses the VM with the specified UUID. |
unpauseVmUuid(string vm_uuid) | Unpauses the VM with the specified UUID. |
rebootVmUuid(string vm_uuid) | Reboots the VM with the specified UUID. |
shutdownVmUuid(string vm_uuid) | Shuts down the VM with the specified UUID. |
startVmUuid(string vm_uuid) | Starts the VM with the specified UUID. |
suspendVmUuidToFile(string vm_uuid, string filename) | Suspends the VM with the specified UUID to the specified file. |
resumeVmUuidFromFile(string vm_uuid, string filename) | Resumes the VM with the specified UUID from the specified file. |
shutdownUnusedVpnvms(void) | Shuts down all VPNVM-type VMs that are not required by any other VMs. |
shutdownDepsOfVm(string vm_name) | Shuts down all dependencies of the named VM that are not required by any other VMs. |
shutdownDepsOfVmUuid(string vm_uuid) | Shuts down all dependencies of the VM with the specified UUID that are not required by any other VMs. |
shutdownVpnvmsForVm(string vm_name) | Shuts down all VPNVM-type dependencies of the named VM that are not required by any other VMs. |
shutdownVpnvmsForVmUuid(string vm_uuid) | Shuts down all VPNVM-type dependencies of the VM with the specified UUID that are not required by any other VMs. |
doNothing(void) | Does nothing. |
printString(string string_to_print) | Prints a string to stdout; primarily for testing purposes. |
logString(string string_to_log) | Prints a string to dom0’s system log. |
runScript(string path_to_script) | Runs the script at the specified path. |
screenOn(void) | Powers on the laptop display. |
screenOff(void) | Powers off the laptop display. |
setBacklight(int backlight_percent) | Sets the display backlight to the specified percentage. |
increaseBacklight(int percent_to_increase) | Increases the backlight by the specified percentage. |
decreaseBacklight(int percent_to_decrease) | Decrease the backlight by the specified percentage. |
...
Backend Architecture
Policy Structure
XCPMD’s policy system is composed of several core pieces:l sources
- sources, or sensors, that react to the system state;
...
- sinks, or actuators, that act upon the system; and
...
- policy that determines how sources activate sinks.
Sources and sinks are provided by dynamically loaded, self-contained modules that register the condition types and action types they provide with the core policy system. The module system is designed to allow easy extension of capabilities and the ability to load platform-dependent implementations of sources/sinks while providing a unified interface to the end user.
...
Variables are simply arguments whose value may change over the life of the program. Variables provide flexibility in configuration and can significantly improve rule readability, both in text form and in the DB. The usual argument type checking is enforced, and safeguards are in place against removing a variable that is currently in use.
Program Flow
The core of XCPMD is a humble libevent event loop, which handles various types of events (socket, DBus, timer, etc) in an orderly queue. The policy system builds on this structure by having its source modules either register their own events or hook into existing events. Once a relevant event occurs, the system determines what conditions rely on it. If any conditions have changed, the system finds the rules that own the changed conditions and evaluates all other conditions of those rules. If the changed condition causes a rule to change from inactive to active or vice versa, that rule’s actions (or undo actions) are then executed. When all rules with changed conditions have been evaluated, the program resumes waiting for events.
...
Source and sink modules are similar, but sources have a few additional tasks to perform and data to track in order to handle events in the way the policy system requires.
Source Modules
A source module should have a struct ev_wrapper for each input event that it handles. These structs are thin wrappers around input events that store information necessary for evaluating any condition_types depending on that event. Each ev_wrapper should have at least one condition_type depending on it, and each condition_type depends on one and only one ev_wrapper. At initialization, ev_wrappers should be registered using add_event() and condition_types should be registered with add_condition_type().
...
Every condition_type provided by a module must have a condition checking function with the following prototype: bool check(struct ev_wrapper *, struct arg_node *). Arguments are passed in as a linked list of struct arg_node; the prototype member must contain a space-separated list of characters describing the number and type of these arguments. Details on the exact format of these prototype strings are available in rules.h. Populating the pretty_prototype member with a C-like, human-readable prototype string is also recommended for self-documentation purposes. Within the condition checking function, arguments should be accessed using the get_arg() function.
Sink Modules
Sink modules, on the other hand, are a bit simpler. Each action_type provided must have an action function with the following prototype: void action(struct arg_node *). Like the arguments to condition checkers, action arguments are passed in as a linked list, whose prototype string must be in the prototype member. These action_types must be registered with add_action_type().
Linking and Symbol Visibility
XCPMD is linked with -rdynamic, which exposes all symbols loaded by the main program to all modules, including symbols from other modules. This greatly simplifies keeping universal data structures consistent across all modules, but has the unfortunate side effect of cluttering the namespace. For this reason, it is essential that all functions provided by modules are either static or uniquely named, including constructors and destructors. Otherwise, shadowing may occur, resulting in one module accidentally calling functions from another.