The set of devices attached to a virtual machine, including permanently installed devices and plug-in devices, is described by an OpenBoot data structure known as the device tree.
The OS can inspect the device tree to determine the hardware configuration of the virtual machine. Each device in the device tree is described by a property list. The set of properties describing a device is arbitrarily extensible so that any type of device and any kind of information that needs to be reported about the device can be accommodated.
The device tree is a hierarchical data structure representing the physical configuration of the virtual machine. Most OpenBoot elements (for example, devices, buses, and libraries of software procedures) are named and located by the device tree.
The device tree also describes user configuration choices, contains firmware device drivers for hardware devices, and contains support routines for use by those drivers. The device tree's structure mimics the organization of the hardware, viewed as a hierarchy of interconnected buses and their attached devices.
The device tree consists of a set of device nodes that are interconnected to form a tree. An individual device node represents either a hardware bus, a hardware device, or a set of interrelated software procedures. The root of the device tree is a node representing the machine’s main physical address bus.
Each device node can have these items:
Properties – Data structures describing the node and its associated device.
Methods – Software procedures used to access the device.
Data – Initial values of the private data used by the methods.
Children – Other device nodes attached to a given node and that lie directly below it in the device tree.
Parent – Node that lies directly above a given node in the device tree.
Device nodes with children are called hierarchical nodes. A node's parent is the node to which it is attached in the device tree. The root node has no parent. Device nodes without children are called leaf nodes.
A node with children usually represents a bus and its associated hardware. Each bus is assumed to define a physical address space; each device connected to that bus has a distinct physical address within that space, uniquely distinguishing the particular device from other devices on that bus. The form of a physical address is bus-specific. The children of a bus node are distinguished from one another with software representations of the same physical addresses that the bus device uses to distinguish attached devices. OpenBoot uses several different representations of addresses with similar meanings but different forms:
Text representation – The human-readable form of a physical address. The format is bus-dependent. For example, some buses use a comma-separated list of numbers represented as ASCII text in hexadecimal notation.
Stack representation – Used to pass arguments to and results from FORTH words. This form usually consists of one or more binary numbers on the data stack.
Property-encoded representation – Used to communicate with client programs through property values. This form usually consists of a sequence of binary numbers stored within an array of bytes.
The forms of these representations differ, but their meanings are the same. They represent physical addresses within a bus's physical address space. The details of these different representations differ from bus to bus, depending on the addressing characteristics of the individual bus. Specifications of OpenBoot address representations for several standard buses are specified in supplements to this document (refer to the IEEE P1275.x documents in 2.1).
Device tree nodes are added by the probing process. Some nodes in the device tree do not represent physical devices. These nodes are used instead for various general purposes in OpenBoot. These nodes do not have physical addresses. Their node names have a device name field but not a unit address field.
The physical address generally represents a physical characteristic unique to the device (such as the bus address or the slot number where the device is installed). The use of physical addresses to identify devices prevents device addresses from changing when other devices are installed or removed.
Each node in the device tree is identified by a node name using the following notation:
device-name@unit-address:device-arguments
Where:
device-name – Is a sequence of between one and 31 letters, digits, and punctuation characters from the set “, . _ + -”. Uppercase and lowercase characters are distinct. By convention, this name includes the name of the device's manufacturer and the device's model name separated by a , (comma). Refer to the definition of name in annex A. Inclusion of the manufacturer name within the device name is especially important for devices intended to plug into standard buses, because this minimizes the risk of accidental name collisions
If the manufacturer name component is omitted (there is no , within the device name), the convention is to assume that the manufacturer name is the same as that of the nearest ancestor node (parent node or grandparent node) that has an explicit manufacturer name component.
unit-address – Is the text representation of the physical address of the device within the address space defined by its parent node. The form of the text representation is bus-dependent.
device-arguments – is a sequence of printable characters other than “/”, “:”, and “@”. Uppercase and lowercase characters are distinct. The length is arbitrary. The device arguments field is interpreted by the driver and typically represents additional device information, such as partition name or protocol. The device arguments field and its preceding “:” can be omitted when specifying a node name, as it does not serve to identify the device node. Instead, it is passed to that node's open method if that driver is opened. By convention, a , (comma) is used to separate subfields within the device arguments field.