MFC r264295:

Remove support of LUN-based CD changers from cd(4) driver.

This code was heavily broken few months ago during CAM locking changes.
Fixing it would require almost complete rewrite.  Since there are no
known devices on market using this interface younger then ~15 years, and
they are CD, not even DVD, I don't see much reason to rewrite it.

This change does not mean those devices won't work.  They will just work
slower due to inefficient disks load/unload schedule if several LUNs
accessed same time.

1 files changed, 1 insertions, 86 deletions

diff --git a/share/man/man4/cd.4 b/share/man/man4/cd.4
index f3a6fc2..495b28d 100644
--- a/share/man/man4/cd.4
+++ b/share/man/man4/cd.4
@@ -25,7 +25,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd February 8, 2012
+.Dd April 9, 2014
 .Dt CD 4
 .Os
 .Sh NAME
@@ -33,8 +33,6 @@
 .Nd SCSI CD-ROM driver
 .Sh SYNOPSIS
 .Cd device cd
-.Cd "options ""CHANGER_MIN_BUSY_SECONDS=3"""
-.Cd "options ""CHANGER_MAX_BUSY_SECONDS=11"""
 .Sh DESCRIPTION
 The
 .Nm
@@ -288,65 +286,6 @@ Some work is planned to support
 some of the more common `broken'
 .Tn CD-ROM
 drives; however, this is not yet under way.
-.Sh CHANGER OPERATION
-This driver has built-in support for LUN-based CD changers.
-A LUN-based CD
-changer is a drive that can hold two or more CDs, but only has one CD
-player mechanism.
-Each CD in the drive shows up as a separate logical unit
-on the
-.Tn SCSI
-bus.
-The
-.Nm
-driver automatically recognizes LUN-based changers, and routes commands for
-changers through an internal scheduler.
-The scheduler prevents changer
-"thrashing", which is caused by sending commands to different LUNs in the
-changer at the same time.
-.Pp
-The scheduler honors minimum and maximum time
-quanta that the driver will spend on a particular LUN.
-The minimum time
-is the guaranteed minimum amount of time that the driver will spend on a
-given LUN, even if there is no outstanding I/O for that LUN.
-The maximum
-time is the maximum amount of time the changer will spend on a LUN if there
-is outstanding I/O for another LUN.
-If there is no outstanding I/O for
-another LUN, the driver will allow indefinite access to a given LUN.
-.Pp
-The minimum and maximum time quanta are configurable via kernel options and
-also via sysctl and kernel tunable variables.
-The kernel options are:
-.Pp
-.Bl -item -compact
-.It
-.Cd "options ""CHANGER_MIN_BUSY_SECONDS=3"""
-.It
-.Cd "options ""CHANGER_MAX_BUSY_SECONDS=11"""
-.El
-.Pp
-The sysctl/kernel tunable variables are:
-.Pp
-.Bl -item -compact
-.It
-.Va kern.cam.cd.changer.min_busy_seconds
-.It
-.Va kern.cam.cd.changer.max_busy_seconds
-.El
-.Pp
-It is suggested that the user try experimenting with the minimum and
-maximum timeouts via the sysctl variables to arrive at the proper values
-for your changer.
-Once you have settled on the proper timeouts for your
-changer, you can then put them in your kernel config file.
-.Pp
-If your system does have a LUN-based changer, you may notice that the
-probe messages for the various LUNs of the changer will continue to appear
-while the boot process is going on.
-This is normal, and is caused by the
-changer scheduling code.
 .Sh SYSCTL VARIABLES
 The following variables are available as both
 .Xr sysctl 8
@@ -397,12 +336,6 @@ Valid minimum command sizes
 are 6 and 10.
 Any value above 6 will be rounded to 10, and any value below
 6 will be rounded to 6.
-.It kern.cam.cd.changer.min_busy_seconds
-.It kern.cam.cd.changer.max_busy_seconds
-.Pp
-Tune how long individual LUNs are 'locked' for I/O operations to
-optimize changer operation.
-See CHANGER OPERATION section for information on how to use these items.
 .El
 .Sh FILES
 .Bl -tag -width /dev/cd[0-9][a-h] -compact
@@ -437,21 +370,3 @@ were poorly chosen, and a number of spelling errors have survived in
 the names of the
 .Fn ioctl
 commands.
-.Pp
-There is no mechanism currently to set different minimum and maximum
-timeouts for different CD changers; the timeout values set by the kernel
-options or the sysctl variables apply to all LUN-based CD changers in the
-system.
-It is possible to implement such support, but the sysctl
-implementation at least would be rather inelegant, because of the current
-inability of the sysctl code to handle the addition of nodes after compile
-time.
-Thus, it would take one dynamically sized sysctl variable and a
-userland utility to get/set the timeout values.
-Implementation of separate
-timeouts for different CD devices in the kernel config file would likely
-require modification of
-.Xr config 8
-to support the two timeouts when hardwiring
-.Nm
-devices.