drvctl
—
tool to rescan busses and detach
devices on user request
drvctl |
-r [-a
attribute] busdevice [locator
...] |
drvctl |
[-n ] -p
device [property ...] |
The drvctl
program works with the
drvctl(4) pseudo-driver to allow the rescan of busses and to detach
drivers from devices.
The following options are available:
-a
- Give the interface attribute where children are to be attached to (and
which defines the interpretation of the locator information). This will
only be needed in rare cases where the bus has multiple attributes. If
there are multiple attributes, and one is not specified,
drvctl
will return an Invalid argument. In such
cases, the -p
option can be used to determine the
available interface attributes.
-d
- Detach the device driver from the device given by the
device argument.
-l
- List the children of the device specified by the
device argument. If device is
not specified, list roots of the device tree instead. Output comes in two
columns. The first column is device, or
“root” if device is not specified. The
second column is the child.
-n
- Suppress first column in
-l
output. Suppress
non-XML headers in -p
output.
-p
- Get properties for the device specified by the
device argument. If property
is specified, the value of that property is printed, otherwise the
properties are displayed as an XML property list. The property can be
given as a path of dictionary keys and numeric array indexes separated by
slashes.
-Q
- Resume the ancestors of device,
device itself, and all of its descendants.
-R
- Resume both the ancestors of device and
device itself.
-r
- Rescan the bus given by the busdevice argument. The
scan range can be restricted by an optional locator
list.
-S
- Suspend both the descendants of device and
device itself.
-t
- Print a tree of devices in
-l
output.
To scan for IDE/SATA/eSATA disks on
atabus1, which need to use the "ata_hl"
attribute:
# drvctl -r -a ata_hl atabus1
A drvctl
utility appeard in
NetBSD 4.0.
Currently, there is no good way to get information about locator
lengths and default values (which is present at kernel configuration time)
out of a running kernel. Thus the locator handling is less intelligent than
it could be.