Device Path Names, Addresses, and Arguments
OpenBoot deals directly with hardware devices in the system. Each device has a unique name representing the type of device and where that device is located in the system addressing structure. The following example shows a full device path name:

/sbus@1f,0/SUNW,fas@e,8800000/sd@3,0:a

A full device path name is a series of node names separated by slashes (/). The root of the tree is the machine node, which is not named explicitly but is indicated by a leading slash (/). Each node name has the form:
driver-name@unit-address:device-arguments
Table 1-1 describes each of these parameters.
Table 1-1 Device Path Name Parameters
Path Name Parameter 
Description 
driver-name
A human-readable string consisting of one to 31 letters, digits and punctuation characters from the set ", . _ + - " that, ideally, has some mnemonic value. Uppercase and lowercase characters are distinct. In some cases, this name includes the name of the device's manufacturer and the device's model name, separated by a comma. Typically, the manufacturer's upper-case, publicly-listed stock symbol is used as the manufacturer's name (e.g. SUNW,sd). For built-in devices, the manufacturer's name is usually omitted (e.g. sbus).
@
Must precede the address parameter. 
unit-address
A text string representing the physical address of the device in its parent's address space. The format of the text is bus dependent.
:
Must precede the arguments parameter.  
device-arguments
A text string, whose format depends on the particular device. It can be used to pass additional information to the device's software.
The full device path name mimics the hardware addressing used by the system to distinguish between different devices. Thus, you can specify a particular device without ambiguity.
In general, the unit-address part of a node name represents an address in the physical address space of its parent. The exact meaning of a particular address depends on the bus to which the device is attached. Consider this example:

/sbus@1f,0/esp@0,40000/sd@3,0:a

<!--[if !supportLists]-->§                        <!--[endif]-->1f,0 represents an address on the main system bus, because the SBus is directly attached to the main system bus in this example.
<!--[if !supportLists]-->§                        <!--[endif]-->0,40000 is an SBus slot number (in other words, 0) and an offset (in other words, 40000), because the esp device is at offset 40000 on the card in SBus slot 0.
<!--[if !supportLists]-->§                        <!--[endif]-->3,0 is a SCSI target and logical unit number, because the disk device is attached to a SCSI bus at target 3, logical unit 0.
When specifying a path name, either the @unit-address or driver-name part of a node name is optional, in which case the firmware tries to pick the device that best matches the given name. If there are several matching nodes, the firmware chooses one (but it may not be the one you want).
For example, using /sbus/esp@0,40000/sd@3,0 assumes that the system in question has exactly one SBus on the main system bus, making sbus as unambiguous an address as sbus@1f,0. On the same system, however, /sbus/esp/sd@3,0 might or might not be ambiguous. Since SBus accepts plug-in cards, there could be more than one esp device on the same SBus bus. If there were more than one on the system, using esp alone would not specify which one, and the firmware might not choose the one you intended.
As another example, /sbus/@2,1/sd@3,0 would normally be unambiguous, while /sbus/scsi@2,1/@3,0 usually would not, since both a SCSI disk device driver and a SCSI tape device driver can use the SCSI target, logical unit address 3,0.
The :device-arguments part of the node name is also optional. Once again, in the example:

/sbus@1f,0/scsi@2,1/sd@3,0:a

the argument for the disk device is a. The software driver for this device interprets its argument as a disk partition, so the device path name refers to partition a on that disk.
Some implementations also enable you to omit path name components. So long as the omission does not create any ambiguity, those implementations will select the device that you intended. For example, if our example system had only one sd device,/sd:a would identify the same device as the much longer preceding expression