cd(9) [freebsd man page]

CD(9)							   BSD Kernel Developer's Manual						     CD(9)

NAME

     cd -- CDROM driver for the CAM SCSI subsystem

DESCRIPTION

     The cd device driver provides a read only interface for CDROM drives (SCSI type 5) and WORM drives (SCSI type 4) that support CDROM type com-
     mands.  Some drives do not behave as the driver expects.  See the QUIRKS section for information on possible flags.

QUIRKS

     Each CD-ROM device can have different interpretations of the SCSI spec.  This can lead to drives requiring special handling in the driver.
     The following is a list of quirks that the driver recognize.

     CD_Q_NO_TOUCH    This flag tells the driver not to probe the drive at attach time to see if there is a disk in the drive and find out what
		      size it is.  This flag is currently unimplemented in the CAM cd driver.

     CD_Q_BCD_TRACKS  This flag is for broken drives that return the track numbers in packed BCD instead of straight decimal.  If the drive seems
		      to skip tracks (tracks 10-15 are skipped) then you have a drive that is in need of this flag.

     CD_Q_NO_CHANGER  This flag tells the driver that the device in question is not a changer.	This is only necessary for a CDROM device with
		      multiple luns that are not a part of a changer.

     CD_Q_CHANGER     This flag tells the driver that the given device is a multi-lun changer.	In general, the driver will figure this out auto-
		      matically when it sees a LUN greater than 0.  Setting this flag only has the effect of telling the driver to run the initial
		      read capacity command for LUN 0 of the changer through the changer scheduling code.

     CD_Q_10_BYTE_ONLY
		      This flag tells the driver that the given device only accepts 10 byte MODE SENSE/MODE SELECT commands.  In general these
		      types of quirks should not be added to the cd(4) driver.	The reason is that the driver does several things to attempt to
		      determine whether the drive in question needs 10 byte commands.  First, it issues a CAM Path Inquiry command to determine
		      whether the protocol that the drive speaks typically only allows 10 byte commands.  (ATAPI and USB are two prominent exam-
		      ples of protocols where you generally only want to send 10 byte commands.)  Then, if it gets an ILLEGAL REQUEST error back
		      from a 6 byte MODE SENSE or MODE SELECT command, it attempts to send the 10 byte version of the command instead.	The only
		      reason you would need a quirk is if your drive uses a protocol (e.g., SCSI) that typically does not have a problem with 6
		      byte commands.

FILES

     /sys/cam/scsi/scsi_cd.c  is the driver source file.

SEE ALSO

     cd(4), scsi(4)

HISTORY

     The cd manual page first appeared in FreeBSD 2.2.

AUTHORS

     This manual page was written by John-Mark Gurney <jmg@FreeBSD.org>.  It was updated for CAM and FreeBSD 3.0 by Kenneth Merry
     <ken@FreeBSD.org>.

BSD
								  March 25, 2014							       BSD

Check Out this Related Man Page

PASS(4) 						   BSD Kernel Interfaces Manual 						   PASS(4)

NAME

     pass -- CAM application passthrough driver

SYNOPSIS

     device pass

DESCRIPTION

     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 access-
     ing SCSI devices, and allows the user to access devices which have no "standard" peripheral driver associated with them.

KERNEL CONFIGURATION

     It is only necessary to configure one pass device in the kernel; pass devices are automatically allocated as SCSI devices are found.

IOCTLS

     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 interface.

     CAMGETPASSTHRU   This ioctl takes an XPT_GDEVLIST CCB, and returns the passthrough device corresponding to the device in question.  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 are issuing this ioctl.	It is probably more useful to issue this ioctl through the
		      xpt(4) device.

FILES

     /dev/passn  Character device nodes for the pass driver.  There should be one of these for each device accessed through the CAM subsystem.

DIAGNOSTICS

     None.

SEE ALSO

     cam(3), cam_cdbparse(3), cam(4), xpt(4), camcontrol(8)

HISTORY

     The CAM passthrough driver first appeared in FreeBSD 3.0.

AUTHORS

     Kenneth Merry <ken@FreeBSD.org>

BUGS

     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

Linux and UNIX Man Pages

cd(9) [freebsd man page]

Check Out this Related Man Page