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>