Device Configuration Procedure Overview

At system boot time, the Configuration Manager is automatically invoked to configure all devices detected and devices whose device information is stored in the Configuration database. At run time, you can configure a specific device by directly invoking a shell command or by using SMIT. This is illustrated in Figure 6-1 on page 6-2.

The system is dynamically configurable. Therefore, it needs a set of rules that defines how to build the system. This building is done by the configuration manager. When the configuration manager is invoked, it reads rules from the Config_Rules object class and performs the indicated actions.

The Config_Rules object class is described in more detail in "Configuration Rules (Config_Rules)" on page B-17.

During system boot time, the Configuration Manager is run in two phases. In phase 1 1 it configures the base devices needed to successfully startup the system. These devices include the root volume group, which permits the Configuration database to be read in from the root file system.

In phase 2 2 the Configuration Manager configures the remaining devices using the Configuration database from the root file system. During this phase,

1 In Phase 1 the Configuration Manager is called as ^N cfgmgr _fN

2 In Phase 2 the Configuration Manager is called as Ncfgmgr _SN

different rules are used depending on the key switch position on the front panel.

If the key position is in service position, the rules for service mode are used.

Otherwise, the normal startup (phase 2) rules are used.

When invoked during run time, the Configuration Manager only uses the phase 2 rules.

Devices in the system are organized in clusters of tree structures known as nodes (Figure 6-3 on page 6-9 provides an example of connections and dependencies of devices in a system).

I

SCSI adapter

I

Tape

I

Disk

I

Token-Ring adapter

TR-IF

TCP/IP

system

system planar

I/O planar

I

I

tty

I

printer RS232 adapter

System Node

I I

Display SIO

adapter (Standard I/O)

I

I

keyboard mouse

adapter adapter

I

display keyboard

I

I

HFf

Fjgure 6-3. Example of Devices Graph

Eac.h tree is a logical subsystem by itself, for example, the System node consists of all the physical devices in the system. The top of the node is the system device. Below the bus are the adapters, which are connected to the bus. The bottom of the hierarchy contains the devices to which no other devices are connected. Most of the pseudo-devices, including HFT and pty, are

organized as separate tree structures or nodes.

Each rule in the Config_Rules object class specifies a program name that the Configuration Manager must execute.

HOW TO LOOK AT Config_Rules - - - ,

To see the Config_Rules object class you need to use the OOM editor. This is done by issuing the "odme Config_Rules" command. The OOM editor is menu driven. Use the cursor keys so that the "Retrieve/Edit objects"

selection is highlighted. Press Enter and the rules are displayed. Press PF3 twice to exit back to an AIX prompt.

The Configuration Manager invokes the programs in the order specified by the sequence value in the rule. In general, the lower the sequence number within a given phase, the higher the priority 3. These programs are typically the configuration programs for the top of the nodes. In invoking these programs, the names of the next lower level devices that need to be configured are

The Configuration Manager begins by invoking a Node Configuration program listed in one of the rules. The Node Configuration program is responsible for starting the configuration process for a node. It does this by querying the Custom.ized database to see if the device at the top of the node is represented in the database. If so, the program writes the logical name of the device to the stdout file and then returns to the Configuration Manager.

The Configuration Manager intercepts the Node Configuration program's stdout file to obtain the names of the devices that were written. It then invokes the configure method for those devices. The device's configure method performs the steps necessary to make the device available. If the device is not an intermediate one, the configure method simply returns to the Configuration Manager. However, if the device is an intermediate device that has child devices, the configure method must determine whether any of the children need to be configured. If so, the configure method writes the names of all the child devices to be configured to the stdout file and then returns to the Configuration Manager.

3 Except for zero, which indicates a don't care condition. Any rule with a sequence number of zero is executed last.

The Configuration Manager intercepts the configure method's stdout file to retrieve the names of the children. It then invokes, one at a time, the configure methods for each child device. Each of these configure methods operate as described for the parent device. For example, they might simply exit when complete, or write to their stdout file a list of additional device names to be configured and then exit. The Configuration Manager will continue to intercept the device names written to the stdout file and to invoke the configure methods for those devices until the configure methods for all the devices have been run and no more names are written to the stdout file.

When a specific device is defined through its define method, the information from the Predefined database for that type of device is used to create the information describing the specific device instance. This specific device instance information is then stored in the Customized database.

The process of configuring a device is often highly device-specific. The configure method for a kernel device needs to:

• Load the device's driver into the kernel

• Pass the Device-Dependent Structure (DDS) describing the device instance to the driver

• Create a special file for the device in the /dev directory.

Of course, many devices do not have device drivers. For this type of device the configured state is not as meaningful. However, it still has a configure method that simply marks the device as configured.

QUICK CONFIGURATION SUMMARY - - - ,

The following is a quick summary of the configuration process:

• Phase 1 configuration only runs at boot time and it configures base devices and logical volume groups.

• Phase 2 configuration runs at boot time and also on demand from the SMIT menus (via the cfgmgr command).

• All configuration phases read the rules in the Config_Rules object class of the ODM database.

• Config_Rules object class defines nodes. The system node as shown in Figure 6-3 on page 6-9 is configured in phase 1 when the Configuration Manager executes the /etc/methods/defsys rule.

• All undetectable devices, i.e. pseudo-devices (pty and HFT) must have a node configuration program so that they can be configured.

• The Configuration Manager calls the config methods of all the devices listed in the node entry of the Config_Rules.

• All devices that have children (i.e. intermediate devices) write their children's names (if they are to be configured) to stdout.

• The Configuration Manager calls the configuration method for all device names that have been written to stdout.

The following figure summarizes how your device would get configured at boot time (assuming you have an entry in the Config_Rules object class of the OOM database).