Attachment 19795 Details for Bug 35089 – file.diff

[patch] file.diff

file.diff (text/plain), 9.35 KB, created by setantae on 2002-02-18 21:10:00 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: setantae

Created: 2002-02-18 21:10:00 UTC

Size: 9.35 KB

patch

obsolete

>--- doc/en_US.ISO8859-1/books/developers-handbook/scsi/chapter.sgml.old	Mon Feb 18 20:58:44 2002
>+++ doc/en_US.ISO8859-1/books/developers-handbook/scsi/chapter.sgml	Mon Feb 18 21:03:16 2002
>@@ -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 @@
> 
>     <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 @@
>       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 @@
>     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 @@
>     <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 @@
> 
>     <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 @@
>       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 @@
> 
>     <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 @@
>         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>

Actions: View | Diff

Attachments on bug 35089: 19795