...

Overview

The power management policy consists of a set of rules, and variables that can be used as arguments in these rules. Policy can currently be loaded from a text file, the DB, or added a rule or variable at a time over DBus. All policy, regardless of origin, is ultimately made persistent by storing it in the DB. 

Rule Structure

A rule consists of a name, a set of conditions, a set of actions, and optionally a set of undo actions. When all conditions become true, the rule becomes active, and its actions are executed in order. When any condition becomes untrue, the rule becomes inactive, and its undo actions (if any) are executed in order.

Name

Each rule is uniquely identified by its name. This name may be used to later modify or remove a rule.  A name may consist of letters, numbers, and underscores.

Name uniqueness is strictly enforced; attempts to add a rule with the same name as a currently loaded rule will fail.

Conditions

A rule’s conditions are a set of Boolean functions that determine when a rule is active. A condition either checks the state of the system or listens for an event. Each condition is individually simple, but more complex rules can be built out of multiple conditions. Multiple conditions are logically ANDed together; therefore, all conditions must be true for a rule to be active. Conditions may be preceded with an exclamation point (!) to invert their return value. If a logical OR is required, consider splitting the conditions into multiple rules with the same actions.

Conditions are able to be selected from a predefined list of condition types, which are enumerated in the Available Conditions section. A condition resembles a C-like function, with a name followed by an open-close pair of parentheses that may contain arguments, according to the condition type’s prototype. Every condition type has a prototype that defines what arguments, if any, it requires. For example, whileBattLessThan() takes two integers as an argument, representing the battery number to check and the percentage to compare to, whereas whileOnBatt() takes no arguments at all. Each condition is separated with spaces, and each argument within each condition is also separated by spaces.

See the Arguments section for specific details on arguments.

Actions

A rule’s actions dictate what a rule will do when it changes from inactive to active. Actions, as their name implies, perform some sort of task, such as pausing a VM or printing a message to the system log. Each action in the list is performed, one at a time, in the order that they are written in the rule’s set of actions.

Much like conditions, each action has a defined prototype determining what arguments it takes. Unlike conditions, however, actions do not evaluate to any particular value; therefore, actions and conditions are in no way interchangeable. Actions, like conditions, also consist of a name followed by a set of parentheses that may contain arguments according to a prototype. When arguments are present, they are separated by spaces. Actions themselves are also separated by spaces.

Undo Actions

Undo actions are performed when a rule changes from active to inactive, but otherwise, the same conventions apply as in the action section. Undo actions may consist of any set of actions. Undo actions are optional, and may be omitted entirely.

Arguments

Arguments are pieces of data provided to conditions and actions. Each argument has a type, which is inferred by the parser. XCPMD currently supports four argument types: 

...

The power management policy consists of a set of rules, and variables that can be used as arguments in these rules. Policy can currently be loaded from a text file, the DB, or added a rule or variable at a time over DBus. All policy, regardless of origin, is ultimately made persistent by storing it in the DB. 

Rule Structure

A rule consists of a name, a set of conditions, a set of actions, and optionally a set of undo actions. When all conditions become true, the rule becomes active, and its actions are executed in order. When any condition becomes untrue, the rule becomes inactive, and its undo actions (if any) are executed in order.

Name

Each rule is uniquely identified by its name. This name may be used to later modify or remove a rule. A name may consist of letters, numbers, and underscores.

Name uniqueness is strictly enforced; attempts to add a rule with the same name as a currently loaded rule will fail.

Conditions

A rule’s conditions are a set of Boolean functions that determine when a rule is active. A condition either checks the state of the system or listens for an event. Each condition is individually simple, but more complex rules can be built out of multiple conditions. Multiple conditions are logically ANDed together; therefore, all conditions must be true for a rule to be active. Conditions may be preceded with an exclamation point (!) to invert their return value. If a logical OR is required, consider splitting the conditions into multiple rules with the same actions.

Conditions are able to be selected from a predefined list of condition types, which are enumerated in the Available Conditions section. A condition resembles a C-like function, with a name followed by an open-close pair of parentheses that may contain arguments, according to the condition type’s prototype. Every condition type has a prototype that defines what arguments, if any, it requires. For example, whileBattLessThan() takes two integers as an argument, representing the battery number to check and the percentage to compare to, whereas whileOnBatt() takes no arguments at all. Each condition is separated with spaces, and each argument within each condition is also separated by spaces.

See the Arguments section for specific details on arguments.

Actions

A rule’s actions dictate what a rule will do when it changes from inactive to active. Actions, as their name implies, perform some sort of task, such as pausing a VM or printing a message to the system log. Each action in the list is performed, one at a time, in the order that they are written in the rule’s set of actions.

Much like conditions, each action has a defined prototype determining what arguments it takes. Unlike conditions, however, actions do not evaluate to any particular value; therefore, actions and conditions are in no way interchangeable. Actions, like conditions, also consist of a name followed by a set of parentheses that may contain arguments according to a prototype. When arguments are present, they are separated by spaces. Actions themselves are also separated by spaces.

Undo Actions

Undo actions are performed when a rule changes from active to inactive, but otherwise, the same conventions apply as in the action section. Undo actions may consist of any set of actions. Undo actions are optional, and may be omitted entirely.

Arguments

Arguments are pieces of data provided to conditions and actions. Each argument has a type, which is inferred by the parser. XCPMD currently supports four argument types: 

• strings, which are enclosed in double-quotes (“); 
• booleans,  which are an unquoted true or falsewhich are an unquoted true or false;

• floats,

   which are numbers containing a decimal point; and 

  which are numbers containing a decimal point; and

• integers,

   which are numbers that do not contain decimal points

  which are numbers that do not contain decimal points.

There is no typeThere is no type-punning;  an integer cannot be substituted for a float, even if their values are equivalentan integer cannot be substituted for a float, even if their values are equivalent.

Example Rule

The following example shows a simple rule with each section separated by pipes The following example shows a simple rule with each section separated by pipes (|):

rule1 | whileOnBatt() whileBattLessThan(0 30) | logString(“Pausing VM!”) pauseVm(“ubuntu”) | unpauseVm(“ubuntu”)

This rule breaks down as followsThis rule breaks down as follows:

• The rule’s name is rule1

  The rule’s name is rule1.

   
• It will become active while it is both on battery power, and battery 0 has less than 30% capacity remaining. When either of these conditions become false, the rule will be inactive.
• When the rule changes from inactive to active, it will print the string “Pausing VM!” to the system log, then pause the VM named “ubuntu.” 
• When the rule changes from active to inactive, it will unpause the VM named “ubuntu

• It will become active while it is both on battery power, and battery 0 has less than 30% capacity remaining. When either of these conditions become false, the rule will be inactive.

• When the rule changes from inactive to active, it will print the string “Pausing VM!” to the system log, then pause the VM named “ubuntu.”

• When the rule changes from active to inactive, it will unpause the VM named “ubuntu.”

Variables

XCPMD also supports variables. Variables are, essentially, arguments whose values can arbitrarily substituted for other values of the same type, serving as an argument to one or more conditions and/or actions. Unlike constant arguments, the value of variables may change even while the daemon is running.

...