os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

"" -> <quote></quote>

Browse source 
Also, fix a typo.

PR:		docs/35089
Submitted by:	Ceri <setantae@submonkey.net>
This commit is contained in:
Murray Stokely 2002-02-19 14:34:11 +00:00
parent fdfdce0cb7
commit 6d7cfec6d8
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=12254
2 changed files with 56 additions and 56 deletions
en_US.ISO8859-1/books
arch-handbook/scsi
chapter.sgml
developers-handbook/scsi
chapter.sgml

56
en_US.ISO8859-1/books/arch-handbook/scsi/chapter.sgml
View file

@ -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>

56
en_US.ISO8859-1/books/developers-handbook/scsi/chapter.sgml
View file

@ -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>