The Configuration Rules (Config_Rules) object class contains the configuration rules used by the Configuration Manager. The Configuration Manager runs in two phases during system boot. The first phase is responsible for configuring the base devices so that the real root device can be configured and made ready for operation. The second phase configures the rest of the devices in the system after the root file system is up and running. The Configuration Manager can also be invoked at run time. The Configuration Manager routine is driven by the rules in the Config_Rules object class.
The Config_Rules object class is preloaded with predefined configuration rules when the system is delivered. There are three types of rules: phase 1, phase 2, and phase 2 service. You can use the ODM commands to add, remove, change, and show new or existing configuration rules in this object class to customize the behavior of the Configuration Manager. However, any changes to a phase 1 rule must be written to the boot file system to be effective. This is done with the bosboot command.
All logical and physical devices in the system are organized in clusters of tree structures called nodes. For information on nodes or tree structures, see the "Device Configuration Manager Overview" in AIX Kernel Extensions and Device Support Programming Concepts. The rules in the Config_Rules object class specify program names that the Configuration Manager executes. Usually, these programs are the configuration programs for the top of the nodes. When these programs are invoked, the names of the next lower-level devices that need to be configured are returned in standard output.
The Configuration Manager configures the next lower-level devices by invoking the Configure method for those devices. In turn, those devices return a list of device names to be configured. This process is repeated until no more device names are returned. All devices in the same node are configured in a transverse order.
The second phase of system boot requires two sets of rules: phase 2 and service. The position of the key on the front panel determines which set of rules is used. The service rules are used when the key is in the service position. If the key is in any other position, the phase 2 rules are used. Different types of rules are indicated in the Configuration Manager Phase descriptor of this object class.
Each configuration rule has an associated boot mask. If this mask has a nonzero value, it represents the type of boot to which the rule applies. For example, if the mask has a DISK_BOOT value, the rule applies to system boots where disks are base devices. The type of boot masks are defined in the /usr/include/sys/cfgdb.h file.
The Config_Rules object class contains the following descriptors:
|ODM Type||Descriptor Name||Description||Descriptor Status|
|ODM_SHORT||phase||Configuration Manager Phase||Required|
|ODM_LONG||boot_mask||Type of boot||Required|
These descriptors are described as follows:
|Configuration Manager Phase|| This descriptor indicates which phase a rule should be executed under phase 1, phase 2, or phase 2 service.
|Sequence Value||In relation to the other rules of this phase, the seq number indicates the order in which to execute this program. In general, the lower the seq number, the higher the priority. For example, a rule with a seq number of 2 is executed before a rule with a seq number of 5. There is one exception to this: a value of 0 indicates a DONT_CARE condition, and any rule with a seq number of 0 is executed last.|
|Type of boot||If the boot_mask field has a nonzero value, it represents the type of boot to which the rule applies. If the -m flag is used when invoking the cfgmgr command, the cfgmgr command applies the specified mask to this field to determine whether to execute the rule. By default, the cfgmgr command always executes a rule for which the boot_mask field has a 0 value.|
|Rule Value|| This is the full path name of the program to be invoked. The rule value descriptor may also contain any options that should be passed to that program. However, options must follow the program name, as the whole string will be executed as if it has been typed in on the command line.
Note: There is one rule for each program to execute. If multiple programs are needed, then multiple rules must be added.
The bosboot command.
Writing a Configure Method.
Writing a Device Method, Device Configuration Manager Overview in AIX Kernel Extensions and Device Support Programming Concepts.
Device Configuration Subsystem Programming Introduction in AIX Kernel Extensions and Device Support Programming Concepts.
Object Data Management (ODM) Overview for Programmers, Understanding ODM Object Classes and Objects in AIX General Programming Concepts: Writing and Debugging Programs.
ODM Device Configuration Object Classes.
Understanding System Boot Processing in AIX Version 4.3 System Management Guide: Operating System and Devices.