91 lines
3.4 KiB
Groff
91 lines
3.4 KiB
Groff
.\" -*- nroff -*-
|
|
.\"
|
|
.\" Copyright (c) 1998 Doug Rabson
|
|
.\"
|
|
.\" All rights reserved.
|
|
.\"
|
|
.\" This program is free software.
|
|
.\"
|
|
.\" Redistribution and use in source and binary forms, with or without
|
|
.\" modification, are permitted provided that the following conditions
|
|
.\" are met:
|
|
.\" 1. Redistributions of source code must retain the above copyright
|
|
.\" notice, this list of conditions and the following disclaimer.
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
|
.\" notice, this list of conditions and the following disclaimer in the
|
|
.\" documentation and/or other materials provided with the distribution.
|
|
.\"
|
|
.\" THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR
|
|
.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
|
.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
|
.\" IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
|
.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
|
.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
.\"
|
|
.\" $FreeBSD$
|
|
.\"
|
|
.Dd June 16, 1998
|
|
.Dt DEVICE_PROBE 9
|
|
.Os
|
|
.Sh NAME
|
|
.Nm DEVICE_PROBE
|
|
.Nd probe for device existence
|
|
.Sh SYNOPSIS
|
|
.In sys/param.h
|
|
.In sys/bus.h
|
|
.Ft int
|
|
.Fn DEVICE_PROBE "device_t dev"
|
|
.Sh DESCRIPTION
|
|
This device method should probe to see if the device is present.
|
|
It should return 0 if the device exists,
|
|
.Er ENXIO
|
|
if it cannot be found.
|
|
If some other error happens during the probe (such as a memory
|
|
allocation 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
|
|
.Ux
|
|
error
|
|
codes should be used for the purpose.
|
|
.Pp
|
|
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.
|
|
.Pp
|
|
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.
|
|
.Sh RETURN VALUES
|
|
A value equal to or less than zero indicates success, greater than
|
|
zero indicates an error (errno).
|
|
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.
|
|
.Sh SEE ALSO
|
|
.Xr device 9 ,
|
|
.Xr DEVICE_ATTACH 9 ,
|
|
.Xr DEVICE_DETACH 9 ,
|
|
.Xr DEVICE_IDENTIFY 9 ,
|
|
.Xr DEVICE_SHUTDOWN 9
|
|
.Sh AUTHORS
|
|
This man page was written by
|
|
.An Doug Rabson .
|