The dependencies that one device has on another can be represented in the configuration database in two ways. One way usually represents physical connections such as a keyboard device connected to a particular keyboard adapter. The keyboard device has a dependency on the keyboard adapter in that it cannot be configured until after the adapter is configured. This relationship is usually referred to as a parent-child relationship, with the adapter as parent and the keyboard device as child. These relationships are represented with the Parent Device Logical Name and Location Where Device Is Connected descriptors in the Customized Devices (CuDv) object class.
The second method represents a logical connection. A device method can add an object identifying both a dependent device and the device upon which it depends to the Customized Dependency (CuDep) object class. The dependent device is considered to have a dependency, and the depended-upon device is considered to be a dependency. CuDep objects are usually added to the database to represent a situation in which one device requires access to another device. For example, the hft0 lft0 device depends upon a particular keyboard or display device.
These two types of dependencies differ significantly. The configuration process uses parent-child dependencies at boot time to configure all devices that make up a node. The CuDep dependency is usually only used by a device's Configure method to retrieve the names of the devices on which it depends. The Configure method can then check to see if those devices exist.
For device methods, the parent-child relationship is the more important. Parent-child relationships affect device-method activities in these ways:
However, when a device is listed as a dependency of another device in the CuDep object class, the only effect is to prevent the depended-upon device from being undefined. The name of the dependency is important to the dependent device. If the depended-upon device were allowed to be undefined, a third device could be defined and assigned the same name.
Writers of Unconfigure and Change methods for a depended-upon device should not worry about whether the device is listed as a dependency. If the depended-upon device is actually open by the other device, the Unconfigure and Change operations will fail because their device is busy. But if the depended-upon device is not currently open, the Unconfigure or Change operations can be performed without affecting the dependent device.
The possible parent-child connections are defined in the Predefined Connection (PdCn) object class. Each predefined device type that can be a parent device is represented in this object class. There is an object for each connection location (such as slots or ports) describing the subclass of devices that can be connected at that location. The subclass is used to identify each device since it indicates the devices' connection type (for example, SCSI or rs232).
There is no corresponding predefined object class describing the possible CuDep dependencies. A device method can be written so that it already knows what the dependencies are. If predefined data is required, it can be added as predefined attributes for the dependent device in the Predefined Attribute (PdAt) object class.
The Devices Graph diagram provides an example of device dependencies and connections in the system.
Customized Dependency (CuDep) Object Class, Customized Devices (CuDv) Object Class in AIX Technical Reference: Kernel and Subsystems Volume 1.
Predefined Attribute (PdAt) Object Class, Predefined Connection (PdCn) Object Class in AIX Version 4.3 Technical Reference: Kernel and Subsystems Volume 1.
