Move dynamic sysctl(8) variable creation for the cd(4) and da(4) drivers

out of cdregister() and daregister(), which are run from interrupt context.

The sysctl code does blocking mallocs (M_WAITOK), which causes problems
if malloc(9) actually needs to sleep.

The eventual fix for this issue will involve moving the CAM probe process
inside a kernel thread.  For now, though, I have fixed the issue by moving
dynamic sysctl variable creation for these two drivers to a task queue
running in a kernel thread.

The existing task queues (taskqueue_swi and taskqueue_swi_giant) run in
software interrupt handlers, which wouldn't fix the problem at hand.  So I
have created a new task queue, taskqueue_thread, that runs inside a kernel
thread.  (It also runs outside of Giant -- clients must explicitly acquire
and release Giant in their taskqueue functions.)

scsi_cd.c:	Remove sysctl variable creation code from cdregister(), and
		move it to a new function, cdsysctlinit().  Queue
		cdsysctlinit() to the taskqueue_thread taskqueue once we
		have fully registered the cd(4) driver instance.

scsi_da.c:	Remove sysctl variable creation code from daregister(), and
		move it to move it to a new function, dasysctlinit().
		Queue dasysctlinit() to the taskqueue_thread taskqueue once
		we have fully registered the da(4) instance.

taskqueue.h:	Declare the new taskqueue_thread taskqueue, update some
		comments.

subr_taskqueue.c:
		Create the new kernel thread taskqueue.  This taskqueue
		runs outside of Giant, so any functions queued to it would
		need to explicitly acquire/release Giant if they need it.

cd.4:		Update the cd(4) man page to talk about the minimum command
		size sysctl/loader tunable.  Also note that the changer
		variables are available as loader tunables as well.

da.4:		Update the da(4) man page to cover the retry_count,
		default_timeout and minimum_cmd_size sysctl variables/loader
		tunables.  Remove references to /dev/r???, they aren't used
		any longer.

cd.9:		Update the cd(9) man page to describe the CD_Q_10_BYTE_ONLY
		quirk.

taskqueue.9:	Update the taskqueue(9) man page to describe the new thread
		task queue, and the taskqueue_swi_giant queue.

MFC after:	3 days

1 files changed, 17 insertions, 1 deletions

diff --git a/share/man/man9/cd.9 b/share/man/man9/cd.9
index 036fc80..49c2ede 100644
--- a/share/man/man9/cd.9
+++ b/share/man/man9/cd.9
@@ -27,7 +27,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd October 10, 1998
+.Dd September 2, 2003
 .Dt CD 9
 .Os
 .Sh NAME
@@ -74,6 +74,22 @@ In general, the driver will figure this out automatically 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.
+.It Dv 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
+.Xr 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 examples 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. 
+.Tn SCSI )
+that typically doesn't have a problem with 6 byte commands.
 .El
 .Sh FILES
 .Bl -tag -width /sys/cam/scsi/scsi_cd.c -compact