PASS(4) BSD Kernel Interfaces Manual PASS(4)
pass -- CAM application passthrough driver
The pass driver provides a way for userland applications to issue CAM
CCBs to the kernel.
Since the pass driver allows direct access to the CAM subsystem, system
administrators should exercise caution when granting access to this
driver. If used improperly, this driver can allow userland applications
to crash a machine or cause data loss.
The pass driver attaches to every SCSI device found in the system. Since
it attaches to every device, it provides a generic means of accessing
SCSI devices, and allows the user to access devices which have no "stan-
dard" peripheral driver associated with them.
It is only necessary to configure one pass device in the kernel; pass
devices are automatically allocated as SCSI devices are found.
CAMIOCOMMAND This ioctl takes most kinds of CAM CCBs and passes them
through to the CAM transport layer for action. Note
that some CCB types are not allowed through the
passthrough device, and must be sent through the xpt(4)
device instead. Some examples of xpt-only CCBs are
XPT_SCAN_BUS, XPT_DEV_MATCH, XPT_RESET_BUS,
XPT_SCAN_LUN, XPT_ENG_INQ, and XPT_ENG_EXEC. These CCB
types have various attributes that make it illogical or
impossible to service them through the passthrough
CAMGETPASSTHRU This ioctl takes an XPT_GDEVLIST CCB, and returns the
passthrough device corresponding to the device in ques-
tion. Although this ioctl is available through the pass
driver, it is of limited use, since the caller must
already know that the device in question is a
passthrough device if they're issuing this ioctl. It is
probably more useful to issue this ioctl through the
/dev/passn Character device nodes for the pass driver. There should be
one of these for each device accessed through the CAM subsys-
cam(3), cam_cdbparse(3), xpt(4), camcontrol(8)
The CAM passthrough driver first appeared in FreeBSD 3.0.
Kenneth Merry <kenATFreeBSD.org>
It might be nice to have a way to asynchronously send CCBs through the
passthrough driver. This would probably require some sort of read/write
interface or an asynchronous ioctl interface.
BSD October 10, 1998 BSD