Device Path Names, Addresses, and Arguments
v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} st1\:*{behavior:url(#ieooui) }
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