Date: Mon, 18 Feb 2002 21:06:33 +0000 From: Ceri <setantae@submonkey.net> To: FreeBSD-gnats-submit@freebsd.org Subject: docs/35089: Developers' Handbook : SCSI chapter minor fixes Message-ID: <E16cuzZ-0000G4-00@rhadamanth.private.submonkey.net>
index | next in thread | raw e-mail
>Number: 35089
>Category: docs
>Synopsis: Developers' Handbook : SCSI chapter minor fixes
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-doc
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: doc-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Feb 18 13:10:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator: Ceri <setantae@submonkey.net>
>Release: FreeBSD 4.5-STABLE i386
>Organization:
>Environment:
System: FreeBSD rhadamanth.private.submonkey.net 4.5-STABLE FreeBSD 4.5-STABLE #0: Tue Feb 12 17:56:57 GMT 2002 setantae@rhadamanth.private.submonkey.net:/usr/obj/usr/src/sys/RHADAMANTH i386
>Description:
- "" -> <quote></quote>
- There is no function called xpt_selease_simq; there is one called
xpt_release_simq, though
Ceri
>How-To-Repeat:
>Fix:
--- 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>
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E16cuzZ-0000G4-00>