svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
DEVICE_PROBE(9)
The method should probe to see if the device is present. It
should return 0 if the device exists, if it cannot be found. If
some other error happens during the probe (such as a memory allo‐
cation failure), an appropriate error code should be returned.
For cases where more than one driver matches a device, a priority
value can be returned. In this case, success codes are values
less than or equal to zero with the highest value representing
the best match. Failure codes are represented by positive values
and the regular error codes should be used for the purpose. If a
driver returns a success code which is less than zero, it must
not assume that it will be the same driver which is attached to
the device. In particular, it must not assume that any values
stored in the softc structure will be available for its attach
method and any resources allocated during probe must be released
and re-allocated if the attach method is called. In addition it
is an absolute requirement that the probe routine have no side
effects whatsoever. The probe routine may be called more than
once before the attach routine is called. If a success code of
zero is returned, the driver can assume that it will be the one
attached, but must not hold any resources when the probe routine
returns. A driver may assume that the softc is preserved when it
returns a success code of zero. A value equal to or less than
zero indicates success, greater than zero indicates an error (er‐
rno). For values equal to or less than zero: zero indicates
highest priority, no further probing is done; for a value less
than zero, the lower the value the lower the priority, e.g. -100
indicates a lower priority than -50. The following values are
used by convention to indicate different strengths of matching in
a probe routine. Except as noted, these are just suggested val‐
ues, and there's nothing magical about them. The device that
cannot be reprobed, and that no possible other driver may exist
(typically legacy drivers who don't follow all the rules, or spe‐
cial needs drivers). The device is supported by a vendor driver.
This is for source or binary drivers that are not yet integrated
into the tree. Its use in the base OS is prohibited. The device
is a normal device matching some plug and play ID. This is the
normal return value for drivers to use. It is intended that
nearly all of the drivers in the tree should return this value.
The driver is a legacy driver, or an otherwise less desirable
driver for a given plug and play ID. The driver has special re‐
quirements like when there are two drivers that support overlap‐
ping series of hardware devices. In this case the one that sup‐
ports the older part of the line would return this value, while
the one that supports the newer ones would return BUS_PROBE_DE‐
FAULT. The driver matches the type of device generally. This
allows drivers to match all serial ports generally, with special‐
ized drivers matching particular types of serial ports that need
special treatment for some reason. The driver matches all un‐
claimed devices on a bus. The device is one example. The driver
expects its parent to tell it which children to manage and no
probing is really done. The device only matches if its parent
bus specifically said to use this driver. This manual page was
written by