From 6d7cfec6d805dc143ebc1ea854ed5a69d08b4747 Mon Sep 17 00:00:00 2001
From: Murray Stokely <murray@FreeBSD.org>
Date: Tue, 19 Feb 2002 14:34:11 +0000
Subject: [PATCH] "" -> <quote></quote> Also, fix a typo.

PR:		docs/35089
Submitted by:	Ceri <setantae@submonkey.net>
---
 .../books/arch-handbook/scsi/chapter.sgml     | 56 +++++++++----------
 .../developers-handbook/scsi/chapter.sgml     | 56 +++++++++----------
 2 files changed, 56 insertions(+), 56 deletions(-)

diff --git a/en_US.ISO8859-1/books/arch-handbook/scsi/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/scsi/chapter.sgml
index 4e9c6e5332..fa00f66106 100644
--- a/en_US.ISO8859-1/books/arch-handbook/scsi/chapter.sgml
+++ b/en_US.ISO8859-1/books/arch-handbook/scsi/chapter.sgml
@@ -36,7 +36,7 @@
    <para>and from the CAM code itself (by Justing T. Gibbs, see
      <filename>/sys/cam/*</filename>).  When some solution looked the
      most logical and was essentially verbatim extracted from the code
-     by Justin Gibbs, I marked it as "recommended".</para>
+     by Justin Gibbs, I marked it as <quote>recommended</quote>.</para>
 
    <para>The document is illustrated with examples in
      pseudo-code. Although sometimes the examples have many details
@@ -174,7 +174,7 @@
 	  </para></listitem>
 
         <listitem><para>driver_name - the name of the actual driver,
-          such as "ncr" or "wds"</para></listitem>
+          such as <quote>ncr</quote> or <quote>wds</quote>.</para></listitem>
 
         <listitem><para><structName>softc</structName> - pointer to the
           driver's internal descriptor for this SCSI card. This
@@ -182,7 +182,7 @@
           data.</para></listitem>
 
         <listitem><para>unit - the controller unit number, for example
-          for controller "wds0" this number will be
+          for controller <quote>wds0</quote> this number will be
           0</para></listitem>
 
         <listitem><para>max_dev_transactions - maximal number of
@@ -237,7 +237,7 @@
 
     <para>A typical example of such an event is a device reset. Each
       transaction and event identifies the devices to which it applies
-      by the means of "path". The target-specific events normally
+      by the means of <quote>path</quote>. The target-specific events normally
       occur during a transaction with this device. So the path from
       that transaction may be re-used to report this event (this is
       safe because the event path is copied in the event reporting
@@ -273,10 +273,10 @@
         (<function>cam_sim_path(sim)</function>)</para></listitem>
 
       <listitem><para>SCSI target number of the device (CAM_TARGET_WILDCARD
-        means "all devices")</para></listitem>
+        means <quote>all devices</quote>)</para></listitem>
 
       <listitem><para>SCSI LUN number of the subdevice (CAM_LUN_WILDCARD means
-        "all LUNs")</para></listitem>
+        <quote>all LUNs</quote>)</para></listitem>
     </itemizedlist>
 
     <para>If the driver can not allocate this path it will not be able to
@@ -324,13 +324,13 @@
 
     <para>Do some action on request of the CAM subsystem. Sim
       describes the SIM for the request, CCB is the request
-      itself. CCB stands for "CAM Control Block". It is a union of
+      itself. CCB stands for <quote>CAM Control Block</quote>. It is a union of
       many specific instances, each describing arguments for some type
       of transactions. All of these instances share the CCB header
       where the common part of arguments is stored.</para>
 
     <para>CAM supports the SCSI controllers working in both initiator
-      ("normal") mode and target (simulating a SCSI device) mode. Here
+      (<quote>normal</quote>) mode and target (simulating a SCSI device) mode. Here
       we only consider the part relevant to the initiator mode.</para>
 
     <para>There are a few function and macros (in other words,
@@ -398,7 +398,7 @@
       are a surprising number of status values defined in
       <filename>/sys/cam/cam.h</filename> which should be able to
       represent the status of a request in great detail.  More
-      interesting yet, the status is in fact a "bitwise or" of an
+      interesting yet, the status is in fact a <quote>bitwise or</quote> of an
       enumerated status value (the lower 6 bits) and possible
       additional flag-like bits (the upper bits).  The enumerated
       values will be discussed later in more detail.  The summary of
@@ -447,7 +447,7 @@
       allowed to sleep, so all the synchronization for resource access
       must be done using SIM or device queue freezing.  Besides the
       aforementioned flags the CAM subsystem provides functions
-      <function>xpt_selease_simq()</function> and
+      <function>xpt_release_simq()</function> and
       <function>xpt_release_devq()</function> to unfreeze the queues
       directly, without passing a CCB to CAM.</para>
 
@@ -497,7 +497,7 @@
       <listitem><para><emphasis>XPT_SCSI_IO</emphasis> - execute an
       I/O transaction</para>
 
-      <para>The instance "struct ccb_scsiio csio" of the union ccb is
+      <para>The instance <quote>struct ccb_scsiio csio</quote> of the union ccb is
         used to transfer the arguments. They are:</para>
 
       <itemizedlist>
@@ -785,8 +785,8 @@
     }</programlisting>
     </listitem>
 
-    <listitem><para><emphasis>XPT_RESET_DEV</emphasis> - send the SCSI "BUS
-    DEVICE RESET" message to a device</para>
+    <listitem><para><emphasis>XPT_RESET_DEV</emphasis> - send the SCSI <quote>BUS
+    DEVICE RESET</quote> message to a device</para>
 
     <para>There is no data transferred in CCB except the header and
       the most interesting argument of it is target_id. Depending on
@@ -877,8 +877,8 @@
     <listitem><para><emphasis>XPT_ABORT</emphasis> - abort the specified
       CCB</para>
 
-    <para>The arguments are transferred in the instance "struct
-      ccb_abort cab" of the union ccb. The only argument field in it
+    <para>The arguments are transferred in the instance <quote>struct
+      ccb_abort cab</quote> of the union ccb. The only argument field in it
       is:</para>
 
     <para><emphasis>abort_ccb</emphasis> - pointer to the CCB to be
@@ -1037,7 +1037,7 @@
     <listitem><para><emphasis>XPT_SET_TRAN_SETTINGS</emphasis> - explicitly
       set values of SCSI transfer settings</para>
 
-    <para>The arguments are transferred in the instance "struct ccb_trans_setting cts" 
+    <para>The arguments are transferred in the instance <quote>struct ccb_trans_setting cts</quote> 
 of the union ccb:</para>
 
     <itemizedlist>
@@ -1096,8 +1096,8 @@ of the union ccb:</para>
 
     <para>The current settings are, as the name says,
       current. Changing them means that the parameters must be
-      re-negotiated on the next transfer.  Again, these "new current
-      settings" are not supposed to be forced on the device, just they
+      re-negotiated on the next transfer.  Again, these <quote>new current
+      settings</quote> are not supposed to be forced on the device, just they
       are used as the initial step of negotiations.  Also they must be
       limited by actual capabilities of the SCSI controller: for
       example, if the SCSI controller has 8-bit bus and the request
@@ -1121,7 +1121,7 @@ of the union ccb:</para>
       in effect</para></listitem>
 
       <listitem><para><emphasis>goal</emphasis> - those requested by
-      setting of the "current" parameters</para></listitem>
+      setting of the <quote>current</quote> parameters</para></listitem>
     </itemizedlist>
 
     <para>The code looks like:</para>
@@ -1207,8 +1207,8 @@ of the union ccb:</para>
     SCSI transfer settings</para>
 
     <para>This operations is the reverse of
-      XPT_SET_TRAN_SETTINGS. Fill up the CCB instance "struct
-      ccb_trans_setting cts" with data as requested by the flags
+      XPT_SET_TRAN_SETTINGS. Fill up the CCB instance <quote>struct
+      ccb_trans_setting cts</quote> with data as requested by the flags
       CCB_TRANS_CURRENT_SETTINGS or CCB_TRANS_USER_SETTINGS (if both
       are set then the existing drivers return the current
       settings). Set all the bits in the valid field.</para></listitem>
@@ -1216,8 +1216,8 @@ of the union ccb:</para>
     <listitem><para><emphasis>XPT_CALC_GEOMETRY</emphasis> - calculate logical
       (BIOS) geometry of the disk</para>
 
-    <para>The arguments are transferred in the instance "struct
-      ccb_calc_geometry ccg" of the union ccb:</para>
+    <para>The arguments are transferred in the instance <quote>struct
+      ccb_calc_geometry ccg</quote> of the union ccb:</para>
 
     <itemizedlist>
 
@@ -1269,7 +1269,7 @@ of the union ccb:</para>
 
     <para>This gives the general idea, the exact calculation depends
       on the quirks of the particular BIOS. If BIOS provides no way
-      set the "extended translation" flag in EEPROM this flag should
+      set the <quote>extended translation</quote> flag in EEPROM this flag should
       normally be assumed equal to 1. Other popular geometries
       are:</para>
 
@@ -1286,8 +1286,8 @@ of the union ccb:</para>
       words get the SIM driver and SCSI controller (also known as HBA
       - Host Bus Adapter) properties</para>
 
-    <para>The properties are returned in the instance "struct
-ccb_pathinq cpi" of the union ccb:</para>
+    <para>The properties are returned in the instance <quote>struct
+ccb_pathinq cpi</quote> of the union ccb:</para>
 
     <itemizedlist>
 
@@ -1534,7 +1534,7 @@ ahc_async(void *callback_arg, u_int32_t code, struct cam_path *path, void *arg)<
 
     <para>The conditions handled by the interrupt routine and the
       details depend very much on the hardware. We consider the set of
-      "typical" conditions.</para>
+      <quote>typical</quote> conditions.</para>
 
     <para>First, we check if a SCSI reset was encountered on the bus
       (probably caused by another SCSI controller on the same SCSI
@@ -1899,7 +1899,7 @@ ahc_async(void *callback_arg, u_int32_t code, struct cam_path *path, void *arg)<
         SCSI bus reset</para></listitem>
 
       <listitem><para><emphasis>CAM_REQ_CMP_ERR</emphasis> -
-        "impossible" SCSI phase occurred or something else as weird or
+        <quote>impossible</quote> SCSI phase occurred or something else as weird or
         just a generic error if further detail is not
         available</para></listitem>
 
diff --git a/en_US.ISO8859-1/books/developers-handbook/scsi/chapter.sgml b/en_US.ISO8859-1/books/developers-handbook/scsi/chapter.sgml
index 4e9c6e5332..fa00f66106 100644
--- a/en_US.ISO8859-1/books/developers-handbook/scsi/chapter.sgml
+++ b/en_US.ISO8859-1/books/developers-handbook/scsi/chapter.sgml
@@ -36,7 +36,7 @@
    <para>and from the CAM code itself (by Justing T. Gibbs, see
      <filename>/sys/cam/*</filename>).  When some solution looked the
      most logical and was essentially verbatim extracted from the code
-     by Justin Gibbs, I marked it as "recommended".</para>
+     by Justin Gibbs, I marked it as <quote>recommended</quote>.</para>
 
    <para>The document is illustrated with examples in
      pseudo-code. Although sometimes the examples have many details
@@ -174,7 +174,7 @@
 	  </para></listitem>
 
         <listitem><para>driver_name - the name of the actual driver,
-          such as "ncr" or "wds"</para></listitem>
+          such as <quote>ncr</quote> or <quote>wds</quote>.</para></listitem>
 
         <listitem><para><structName>softc</structName> - pointer to the
           driver's internal descriptor for this SCSI card. This
@@ -182,7 +182,7 @@
           data.</para></listitem>
 
         <listitem><para>unit - the controller unit number, for example
-          for controller "wds0" this number will be
+          for controller <quote>wds0</quote> this number will be
           0</para></listitem>
 
         <listitem><para>max_dev_transactions - maximal number of
@@ -237,7 +237,7 @@
 
     <para>A typical example of such an event is a device reset. Each
       transaction and event identifies the devices to which it applies
-      by the means of "path". The target-specific events normally
+      by the means of <quote>path</quote>. The target-specific events normally
       occur during a transaction with this device. So the path from
       that transaction may be re-used to report this event (this is
       safe because the event path is copied in the event reporting
@@ -273,10 +273,10 @@
         (<function>cam_sim_path(sim)</function>)</para></listitem>
 
       <listitem><para>SCSI target number of the device (CAM_TARGET_WILDCARD
-        means "all devices")</para></listitem>
+        means <quote>all devices</quote>)</para></listitem>
 
       <listitem><para>SCSI LUN number of the subdevice (CAM_LUN_WILDCARD means
-        "all LUNs")</para></listitem>
+        <quote>all LUNs</quote>)</para></listitem>
     </itemizedlist>
 
     <para>If the driver can not allocate this path it will not be able to
@@ -324,13 +324,13 @@
 
     <para>Do some action on request of the CAM subsystem. Sim
       describes the SIM for the request, CCB is the request
-      itself. CCB stands for "CAM Control Block". It is a union of
+      itself. CCB stands for <quote>CAM Control Block</quote>. It is a union of
       many specific instances, each describing arguments for some type
       of transactions. All of these instances share the CCB header
       where the common part of arguments is stored.</para>
 
     <para>CAM supports the SCSI controllers working in both initiator
-      ("normal") mode and target (simulating a SCSI device) mode. Here
+      (<quote>normal</quote>) mode and target (simulating a SCSI device) mode. Here
       we only consider the part relevant to the initiator mode.</para>
 
     <para>There are a few function and macros (in other words,
@@ -398,7 +398,7 @@
       are a surprising number of status values defined in
       <filename>/sys/cam/cam.h</filename> which should be able to
       represent the status of a request in great detail.  More
-      interesting yet, the status is in fact a "bitwise or" of an
+      interesting yet, the status is in fact a <quote>bitwise or</quote> of an
       enumerated status value (the lower 6 bits) and possible
       additional flag-like bits (the upper bits).  The enumerated
       values will be discussed later in more detail.  The summary of
@@ -447,7 +447,7 @@
       allowed to sleep, so all the synchronization for resource access
       must be done using SIM or device queue freezing.  Besides the
       aforementioned flags the CAM subsystem provides functions
-      <function>xpt_selease_simq()</function> and
+      <function>xpt_release_simq()</function> and
       <function>xpt_release_devq()</function> to unfreeze the queues
       directly, without passing a CCB to CAM.</para>
 
@@ -497,7 +497,7 @@
       <listitem><para><emphasis>XPT_SCSI_IO</emphasis> - execute an
       I/O transaction</para>
 
-      <para>The instance "struct ccb_scsiio csio" of the union ccb is
+      <para>The instance <quote>struct ccb_scsiio csio</quote> of the union ccb is
         used to transfer the arguments. They are:</para>
 
       <itemizedlist>
@@ -785,8 +785,8 @@
     }</programlisting>
     </listitem>
 
-    <listitem><para><emphasis>XPT_RESET_DEV</emphasis> - send the SCSI "BUS
-    DEVICE RESET" message to a device</para>
+    <listitem><para><emphasis>XPT_RESET_DEV</emphasis> - send the SCSI <quote>BUS
+    DEVICE RESET</quote> message to a device</para>
 
     <para>There is no data transferred in CCB except the header and
       the most interesting argument of it is target_id. Depending on
@@ -877,8 +877,8 @@
     <listitem><para><emphasis>XPT_ABORT</emphasis> - abort the specified
       CCB</para>
 
-    <para>The arguments are transferred in the instance "struct
-      ccb_abort cab" of the union ccb. The only argument field in it
+    <para>The arguments are transferred in the instance <quote>struct
+      ccb_abort cab</quote> of the union ccb. The only argument field in it
       is:</para>
 
     <para><emphasis>abort_ccb</emphasis> - pointer to the CCB to be
@@ -1037,7 +1037,7 @@
     <listitem><para><emphasis>XPT_SET_TRAN_SETTINGS</emphasis> - explicitly
       set values of SCSI transfer settings</para>
 
-    <para>The arguments are transferred in the instance "struct ccb_trans_setting cts" 
+    <para>The arguments are transferred in the instance <quote>struct ccb_trans_setting cts</quote> 
 of the union ccb:</para>
 
     <itemizedlist>
@@ -1096,8 +1096,8 @@ of the union ccb:</para>
 
     <para>The current settings are, as the name says,
       current. Changing them means that the parameters must be
-      re-negotiated on the next transfer.  Again, these "new current
-      settings" are not supposed to be forced on the device, just they
+      re-negotiated on the next transfer.  Again, these <quote>new current
+      settings</quote> are not supposed to be forced on the device, just they
       are used as the initial step of negotiations.  Also they must be
       limited by actual capabilities of the SCSI controller: for
       example, if the SCSI controller has 8-bit bus and the request
@@ -1121,7 +1121,7 @@ of the union ccb:</para>
       in effect</para></listitem>
 
       <listitem><para><emphasis>goal</emphasis> - those requested by
-      setting of the "current" parameters</para></listitem>
+      setting of the <quote>current</quote> parameters</para></listitem>
     </itemizedlist>
 
     <para>The code looks like:</para>
@@ -1207,8 +1207,8 @@ of the union ccb:</para>
     SCSI transfer settings</para>
 
     <para>This operations is the reverse of
-      XPT_SET_TRAN_SETTINGS. Fill up the CCB instance "struct
-      ccb_trans_setting cts" with data as requested by the flags
+      XPT_SET_TRAN_SETTINGS. Fill up the CCB instance <quote>struct
+      ccb_trans_setting cts</quote> with data as requested by the flags
       CCB_TRANS_CURRENT_SETTINGS or CCB_TRANS_USER_SETTINGS (if both
       are set then the existing drivers return the current
       settings). Set all the bits in the valid field.</para></listitem>
@@ -1216,8 +1216,8 @@ of the union ccb:</para>
     <listitem><para><emphasis>XPT_CALC_GEOMETRY</emphasis> - calculate logical
       (BIOS) geometry of the disk</para>
 
-    <para>The arguments are transferred in the instance "struct
-      ccb_calc_geometry ccg" of the union ccb:</para>
+    <para>The arguments are transferred in the instance <quote>struct
+      ccb_calc_geometry ccg</quote> of the union ccb:</para>
 
     <itemizedlist>
 
@@ -1269,7 +1269,7 @@ of the union ccb:</para>
 
     <para>This gives the general idea, the exact calculation depends
       on the quirks of the particular BIOS. If BIOS provides no way
-      set the "extended translation" flag in EEPROM this flag should
+      set the <quote>extended translation</quote> flag in EEPROM this flag should
       normally be assumed equal to 1. Other popular geometries
       are:</para>
 
@@ -1286,8 +1286,8 @@ of the union ccb:</para>
       words get the SIM driver and SCSI controller (also known as HBA
       - Host Bus Adapter) properties</para>
 
-    <para>The properties are returned in the instance "struct
-ccb_pathinq cpi" of the union ccb:</para>
+    <para>The properties are returned in the instance <quote>struct
+ccb_pathinq cpi</quote> of the union ccb:</para>
 
     <itemizedlist>
 
@@ -1534,7 +1534,7 @@ ahc_async(void *callback_arg, u_int32_t code, struct cam_path *path, void *arg)<
 
     <para>The conditions handled by the interrupt routine and the
       details depend very much on the hardware. We consider the set of
-      "typical" conditions.</para>
+      <quote>typical</quote> conditions.</para>
 
     <para>First, we check if a SCSI reset was encountered on the bus
       (probably caused by another SCSI controller on the same SCSI
@@ -1899,7 +1899,7 @@ ahc_async(void *callback_arg, u_int32_t code, struct cam_path *path, void *arg)<
         SCSI bus reset</para></listitem>
 
       <listitem><para><emphasis>CAM_REQ_CMP_ERR</emphasis> -
-        "impossible" SCSI phase occurred or something else as weird or
+        <quote>impossible</quote> SCSI phase occurred or something else as weird or
         just a generic error if further detail is not
         available</para></listitem>