Attachment 221358 Details for Bug 252493 – Corrected patch

[patch] Corrected patch

because-articles2.diff (text/plain), 20.63 KB, created by Ceri Davies on 2021-01-07 17:53:51 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Ceri Davies

Created: 2021-01-07 17:53:51 UTC

Size: 20.63 KB

patch

obsolete

>diff --git a/en_US.ISO8859-1/articles/committers-guide/article.xml b/en_US.ISO8859-1/articles/committers-guide/article.xml
>index e05587a219..db04ddd5f0 100644
>--- a/en_US.ISO8859-1/articles/committers-guide/article.xml
>+++ b/en_US.ISO8859-1/articles/committers-guide/article.xml
>@@ -1280,7 +1280,7 @@ You need a Passphrase to protect your secret key.</screen>
> 	<sect4>
> 	  <title>Preparing the Merge Target</title>
> 
>-	  <para>Because of the mergeinfo propagation issues described
>+	  <para>Due to the mergeinfo propagation issues described
> 	    earlier, it is very important to never merge changes
> 	    into a sparse working copy.  Always use a full
> 	    checkout of the branch being merged into.  For instance,
>diff --git a/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml b/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml
>index cb5064aa5c..eda3c20709 100644
>--- a/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml
>+++ b/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml
>@@ -33,7 +33,7 @@
>       thinking, the missing historical context, the ambiguous
>       standards - and the style(9) transgressions.</para>
> 
>-    <para>Because Bruce gave more code reviews than anybody else in
>+    <para>As Bruce gave more code reviews than anybody else in
>       the history of the FreeBSD project, the commit logs hide the
>       true scale of his impact until you pay attention to
>       "Submitted by", "Reviewed by" and "Pointed out by".</para>
>diff --git a/en_US.ISO8859-1/articles/ldap-auth/article.xml b/en_US.ISO8859-1/articles/ldap-auth/article.xml
>index d1957adb4f..26ecdf7f29 100644
>--- a/en_US.ISO8859-1/articles/ldap-auth/article.xml
>+++ b/en_US.ISO8859-1/articles/ldap-auth/article.xml
>@@ -617,7 +617,7 @@ passwd: files ldap</programlisting>
> 
>       <para>Unfortunately, as of the time this was written &os; did
> 	not support changing user passwords with &man.passwd.1;.
>-	Because of this, most administrators are left to implement a
>+	As a result of this, most administrators are left to implement a
> 	solution themselves.  I provide some examples here.  Note that
> 	if you write your own password change script, there are some
> 	security issues you should be made aware of; see <xref
>diff --git a/en_US.ISO8859-1/articles/linux-emulation/article.xml b/en_US.ISO8859-1/articles/linux-emulation/article.xml
>index d3e6c8742e..489b88168c 100644
>--- a/en_US.ISO8859-1/articles/linux-emulation/article.xml
>+++ b/en_US.ISO8859-1/articles/linux-emulation/article.xml
>@@ -403,7 +403,7 @@
> 	    different API(es).  The M:N library uses the
> 	    <literal>kse_*</literal> family of syscalls while the 1:1
> 	    library uses the <literal>thr_*</literal> family of
>-	    syscalls.  Because of this, there is no general concept of
>+	    syscalls.  Due to this, there is no general concept of
> 	    thread ID shared between kernel and userspace.  Of course,
> 	    both threading libraries implement the pthread thread ID
> 	    API.  Every kernel thread (as described by <literal>struct
>@@ -1683,7 +1683,7 @@ translate_traps(int signal, int trap_code)
>       <sect3 xml:id="pid-mangling">
> 	<title>PID mangling</title>
> 
>-	<para>Because of the described different view knowing what a
>+	<para>As there is a difference in view as what to the idea of a
> 	  process ID and thread ID is between &os; and &linux; we have
> 	  to translate the view somehow.  We do it by PID mangling.
> 	  This means that we fake what a PID (=TGID) and TID (=PID) is
>@@ -1783,7 +1783,7 @@ void * child_tidptr);</programlisting>
> 	  <literal>linux_emuldata_shared</literal>.  The
> 	  <literal>emul_lock</literal> is a nonsleepable blocking
> 	  mutex while <literal>emul_shared_lock</literal> is a
>-	  sleepable blocking <literal>sx_lock</literal>.  Because of
>+	  sleepable blocking <literal>sx_lock</literal>.  Due to
> 	  the per-subsystem locking we can coalesce some locks and
> 	  that is why the em find offers the non-locking
> 	  access.</para>
>@@ -1981,7 +1981,7 @@ void * child_tidptr);</programlisting>
> 
> 	<para>Threaded programs should be written with as little
> 	  contention on locks as possible.  Otherwise, instead of
>-	  doing useful work the thread just waits on a lock.  Because
>+	  doing useful work the thread just waits on a lock.  As a result
> 	  of this, the most well written threaded programs show little
> 	  locks contention.</para>
>       </sect3>
>diff --git a/en_US.ISO8859-1/articles/serial-uart/article.xml b/en_US.ISO8859-1/articles/serial-uart/article.xml
>index e57b052b9e..2ddbfbe2aa 100644
>--- a/en_US.ISO8859-1/articles/serial-uart/article.xml
>+++ b/en_US.ISO8859-1/articles/serial-uart/article.xml
>@@ -160,7 +160,7 @@
> 	  for the new word can be sent as soon as the Stop Bit for the
> 	  previous word has been sent.</para>
> 
>-	<para>Because asynchronous data is <quote>self
>+	<para>As asynchronous data is <quote>self
> 	  synchronizing</quote>, if there is no data to transmit, the
> 	  transmission line can be idle.</para>
>       </sect2>
>@@ -605,7 +605,7 @@
> 	<title>Bits, Baud and Symbols</title>
> 
> 	<para>Baud is a measurement of transmission speed in
>-	  asynchronous communication.  Because of advances in modem
>+	  asynchronous communication.  Due to advances in modem
> 	  communication technology, this term is frequently misused
> 	  when describing the data rates in newer devices.</para>
> 
>@@ -676,7 +676,7 @@
> 	  DCE speed because of the use of compression by the
> 	  modems.</para>
> 
>-	<para>Because the number of bits needed to describe a byte
>+	<para>As the number of bits needed to describe a byte
> 	  varied during the trip between the two machines plus the
> 	  differing bits-per-seconds speeds that are used present on
> 	  the DTE-DCE and DCE-DCE links, the usage of the term Baud to
>@@ -769,7 +769,7 @@
> 		  technology with various functional flaws
> 		  corrected. The INS8250A was used initially in PC
> 		  clone computers by vendors who used
>-		  <quote>clean</quote> BIOS designs. Because of the
>+		  <quote>clean</quote> BIOS designs. Due to the
> 		  corrections in the chip, this part could not be used
> 		  with a BIOS compatible with the INS8250 or
> 		  INS8250B.</para>
>@@ -949,7 +949,7 @@
> 	<para>In internal modems, the modem designer will frequently
> 	  emulate the 8250A/16450 with the modem microprocessor, and
> 	  the emulated UART will frequently have a hidden buffer
>-	  consisting of several hundred bytes.  Because of the size of
>+	  consisting of several hundred bytes.  Due to the size of
> 	  the buffer, these emulations can be as reliable as a 16550A
> 	  in their ability to handle high speed data.  However, most
> 	  operating systems will still report that the UART is only a
>@@ -971,7 +971,7 @@
> 	<para>When the NS16550 was developed, the National
> 	  Semiconductor obtained several patents on the design and
> 	  they also limited licensing, making it harder for other
>-	  vendors to provide a chip with similar features.  Because of
>+	  vendors to provide a chip with similar features.  As a result of
> 	  the patents, reverse-engineered designs and emulations had
> 	  to avoid infringing the claims covered by the patents.
> 	  Subsequently, these copies almost never perform exactly the
>@@ -1008,7 +1008,7 @@
> 	  TI, StarTech, and CMD as well as megacells and emulations
> 	  embedded in internal modems were tested with COMTEST.  A
> 	  difference count for some of these components is listed
>-	  below. Because these tests were performed in 1994, they may
>+	  below. Since these tests were performed in 1994, they may
> 	  not reflect the current performance of the given product
> 	  from a vendor.</para>
> 
>@@ -1954,7 +1954,7 @@
> 	    produce intelligent serial communication boards.  This type of
> 	    design usually provides a microprocessor that interfaces with
> 	    several UARTs, processes and buffers the data, and then alerts the
>-	    main PC processor when necessary.  Because the UARTs are not
>+	    main PC processor when necessary.  As the UARTs are not
> 	    directly accessed by the PC processor in this type of
> 	    communication system, it is not necessary for the vendor to use
> 	    UARTs that are compatible with the 8250, 16450, or the 16550 UART.
>diff --git a/en_US.ISO8859-1/articles/solid-state/article.xml b/en_US.ISO8859-1/articles/solid-state/article.xml
>index 232a5d59f4..0a0965866b 100644
>--- a/en_US.ISO8859-1/articles/solid-state/article.xml
>+++ b/en_US.ISO8859-1/articles/solid-state/article.xml
>@@ -136,7 +136,7 @@
> 
>     <para>All embedded &os; systems that use flash memory as system
>       disk will be interested in memory disks and memory filesystems.
>-      Because of the limited number of writes that can be done to
>+      As a result of the limited number of writes that can be done to
>       flash memory, the disk and the filesystems on the disk will most
>       likely be mounted read-only.  In this environment, filesystems
>       such as <filename>/tmp</filename> and <filename>/var</filename>
>@@ -223,16 +223,16 @@ pseudo-device   md              # memory disk</programlisting>
>   <sect1>
>     <title>Building a File System from Scratch</title>
> 
>-    <para>Because ATA compatible compact-flash cards are seen by &os;
>+    <para>As ATA compatible compact-flash cards are seen by &os;
>       as normal IDE hard drives, you could theoretically install &os;
>       from the network using the kern and mfsroot floppies or from a
>       CD.</para>
> 
>     <para>However, even a small installation of &os; using normal
>       installation procedures can produce a system in size of greater
>-      than 200 megabytes.  Because most people will be using smaller
>+      than 200 megabytes.  Most people will be using smaller
>       flash memory devices (128 megabytes is considered fairly large -
>-      32 or even 16 megabytes is common) an installation using normal
>+      32 or even 16 megabytes is common), so an installation using normal
>       mechanisms is not possible&mdash;there is simply not enough disk
>       space for even the smallest of conventional
>       installations.</para>
>@@ -423,7 +423,7 @@ pseudo-device   md              # memory disk</programlisting>
> 	successfully run <command>make</command>
> 	<buildtarget>install</buildtarget>, we must create a packages
> 	directory on a non-memory filesystem that will keep track of
>-	our packages across reboots.  Because it is necessary to mount
>+	our packages across reboots.  As it is necessary to mount
> 	your filesystems as read-write for the installation of a
> 	package anyway, it is sensible to assume that an area on the
> 	flash media can also be used for package information to be
>diff --git a/en_US.ISO8859-1/articles/vm-design/article.xml b/en_US.ISO8859-1/articles/vm-design/article.xml
>index 2cf7e001eb..79b56d296c 100644
>--- a/en_US.ISO8859-1/articles/vm-design/article.xml
>+++ b/en_US.ISO8859-1/articles/vm-design/article.xml
>@@ -648,7 +648,7 @@
> 	    cannot be combined with the next A-B sequence.</para>
> 
> 	  <para>Why do we interleave our swap space instead of just tack swap
>-	    areas onto the end and do something fancier?  Because it is a whole
>+	    areas onto the end and do something fancier?  It is a whole
> 	    lot easier to allocate linear swaths of an address space and have
> 	    the result automatically be interleaved across multiple disks than
> 	    it is to try to put that sophistication elsewhere.</para>
>diff --git a/en_US.ISO8859-1/books/arch-handbook/boot/chapter.xml b/en_US.ISO8859-1/books/arch-handbook/boot/chapter.xml
>index 65f8c6cfd0..798b7bc6d9 100644
>--- a/en_US.ISO8859-1/books/arch-handbook/boot/chapter.xml
>+++ b/en_US.ISO8859-1/books/arch-handbook/boot/chapter.xml
>@@ -404,7 +404,7 @@ FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610</screen></entr
>       jmp main-0x7c00+0x600	# Jump to relocated code</programlisting>
>     </figure>
> 
>-    <para>Because <filename>boot0</filename> is loaded by the
>+    <para>As <filename>boot0</filename> is loaded by the
>       <acronym>BIOS</acronym> to address <literal>0x7C00</literal>, it
>       copies itself to address <literal>0x600</literal> and then
>       transfers control there (recall that it was linked to execute at
>@@ -1021,7 +1021,7 @@ main.3:
>       bytes of <filename>boot</filename> and, because
>       <filename>boot</filename> is written to the first sector of the
>       &os; slice, <filename>boot1</filename> fits exactly in this
>-      first sector.  Because <literal>nread</literal> reads the first
>+      first sector.  When <literal>nread</literal> reads the first
>       16 sectors of the &os; slice, it effectively reads the entire
>       <filename>boot</filename> file
>       <footnote>
>@@ -1440,7 +1440,7 @@ init:		cli				# Disable interrupts
>       flags in the EFLAGS register.  Note that the
>       <literal>popfl</literal> instruction pops out a doubleword (4
>       bytes) from the stack and places it in the EFLAGS register.
>-      Because the value actually popped is <literal>2</literal>, the
>+      As the value actually popped is <literal>2</literal>, the
>       EFLAGS register is effectively cleared (IA-32 requires that bit
>       2 of the EFLAGS register always be 1).</para>
> 
>@@ -1583,7 +1583,7 @@ init.3:		lea 0x8(%di),%di		# Next entry
>       abstraction.  The IA-32 architecture demands the creation and
>       use of <emphasis>at least</emphasis> one <acronym>TSS</acronym>
>       if multitasking facilities are used or different privilege
>-      levels are defined.  Because the <filename>boot2</filename>
>+      levels are defined.  Since the <filename>boot2</filename>
>       client is executed in privilege level 3, but the
>       <acronym>BTX</acronym> server does in privilege level 0, a
>       <acronym>TSS</acronym> must be defined:</para>
>diff --git a/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.xml b/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.xml
>index 6e5551873b..9826e3a1d9 100644
>--- a/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.xml
>+++ b/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.xml
>@@ -397,10 +397,10 @@ Closing device "echo".</screen>
>     <para>For this reason, no serious applications rely on block
>       devices, and in fact, almost all applications which access
>       disks directly take great pains to specify that character
>-      (or <quote>raw</quote>) devices should always be used.  Because
>+      (or <quote>raw</quote>) devices should always be used.  As
>       the implementation of the aliasing of each disk (partition) to
>       two devices with different semantics significantly complicated
>-      the relevant kernel code &os; dropped support for cached disk
>+      the relevant kernel code, &os; dropped support for cached disk
>       devices as part of the modernization of the disk I/O
>       infrastructure.</para>
>   </sect1>
>diff --git a/en_US.ISO8859-1/books/arch-handbook/isa/chapter.xml b/en_US.ISO8859-1/books/arch-handbook/isa/chapter.xml
>index 97bd2822c5..04de498a3f 100644
>--- a/en_US.ISO8859-1/books/arch-handbook/isa/chapter.xml
>+++ b/en_US.ISO8859-1/books/arch-handbook/isa/chapter.xml
>@@ -375,7 +375,7 @@
>         with PnP. This feature is not implemented in any existing
>         driver and is not considered further in this document.</para>
> 
>-      <para>Because the PnP devices are disabled when probing the
>+      <para>As the PnP devices are disabled when probing the
>         legacy devices they will not be attached twice (once as legacy
>         and once as PnP).  But in case of device-dependent identify
>         routines it is the responsibility of the driver to make sure
>@@ -1019,7 +1019,7 @@
>               Free the memory allocated by
>               <function>bus_dmamem_alloc()</function>. At present,
>               freeing of the memory allocated with ISA restrictions is
>-              not implemented.  Because of this the recommended model
>+              not implemented.  Due to this the recommended model
>               of use is to keep and re-use the allocated areas for as
>               long as possible. Do not lightly free some area and then
>               shortly allocate it again. That does not mean that
>@@ -1322,11 +1322,11 @@
>           Before calling the callback function from
>           <function>bus_dmamap_load()</function> the segment array is
>           stored in the stack. And it gets pre-allocated for the
>-          maximal number of segments allowed by the tag. Because of
>+          maximal number of segments allowed by the tag. As a result of
>           this the practical limit for the number of segments on i386
>           architecture is about 250-300 (the kernel stack is 4KB minus
>           the size of the user structure, size of a segment array
>-          entry is 8 bytes, and some space must be left). Because the
>+          entry is 8 bytes, and some space must be left). Since the
>           array is allocated based on the maximal number this value
>           must not be set higher than really needed. Fortunately, for
>           most of hardware the maximal supported number of segments is
>@@ -2192,7 +2192,7 @@
>           int error = 0;</programlisting>
> 
>         <para>Then allocate and activate all the necessary
>-          resources. Because normally the port range will be released
>+          resources. As normally the port range will be released
>           before returning from probe, it has to be allocated
>           again. We expect that the probe routine had properly set all
>           the resource ranges, as well as saved them in the structure
>diff --git a/en_US.ISO8859-1/books/arch-handbook/pccard/chapter.xml b/en_US.ISO8859-1/books/arch-handbook/pccard/chapter.xml
>index a9a2753d9a..59261a9568 100644
>--- a/en_US.ISO8859-1/books/arch-handbook/pccard/chapter.xml
>+++ b/en_US.ISO8859-1/books/arch-handbook/pccard/chapter.xml
>@@ -52,7 +52,7 @@
>       <indexterm><primary>Linksys</primary></indexterm>
>       <indexterm><primary>D-Link</primary></indexterm>
> 
>-      <para>Because of this practice, FreeBSD drivers usually rely on
>+      <para>Due to this practice, FreeBSD drivers usually rely on
> 	numeric IDs for device identification.  Using numeric IDs and
> 	a centralized database complicates adding IDs and support for
> 	cards to the system.  One must carefully check to see who
>diff --git a/en_US.ISO8859-1/books/arch-handbook/scsi/chapter.xml b/en_US.ISO8859-1/books/arch-handbook/scsi/chapter.xml
>index c325840bed..7de627b5b9 100644
>--- a/en_US.ISO8859-1/books/arch-handbook/scsi/chapter.xml
>+++ b/en_US.ISO8859-1/books/arch-handbook/scsi/chapter.xml
>@@ -103,7 +103,7 @@
>       then also converting the SCSI commands to the native commands of
>       the hardware).</para>
> 
>-    <para>Because we are interested in writing a SCSI adapter driver
>+    <para>As we are interested in writing a SCSI adapter driver
>       here, from this point on we will consider everything from the
>       SIM standpoint.</para>
> 
>@@ -1076,7 +1076,7 @@
> 	  the timeout to make sure that the target is not sleeping
> 	  forever.  If the command would not get aborted in some
> 	  reasonable time like 10 seconds the timeout routine would go
>-	  ahead and reset the whole SCSI bus.  Because the command
>+	  ahead and reset the whole SCSI bus.  Since the command
> 	  will be aborted in some reasonable time we can just return
> 	  the abort request now as successfully completed, and mark
> 	  the aborted CCB as aborted (but not mark it as done
>@@ -1116,7 +1116,7 @@
>     return;</programlisting>
> 
> 	<para>That is all for the ABORT request, although there is one
>-	  more issue.  Because the ABORT message cleans all the
>+	  more issue.  As the ABORT message cleans all the
> 	  ongoing transactions on a LUN we have to mark all the other
> 	  active transactions on this LUN as aborted.  That should be
> 	  done in the interrupt routine, after the transaction gets
>@@ -1634,7 +1634,7 @@
>       routine (or the other way around, the poll routine may be doing
>       the real action and the interrupt routine would just call the
>       poll routine).  Why bother about a separate function then?
>-      Because of different calling conventions.  The
>+      Due to different calling conventions.  The
>       <function>xxx_poll</function> routine gets the struct cam_sim
>       pointer as its argument when the PCI interrupt routine by common
>       convention gets pointer to the struct
>diff --git a/en_US.ISO8859-1/books/arch-handbook/usb/chapter.xml b/en_US.ISO8859-1/books/arch-handbook/usb/chapter.xml
>index 6fa02b2d59..1d34c3192b 100644
>--- a/en_US.ISO8859-1/books/arch-handbook/usb/chapter.xml
>+++ b/en_US.ISO8859-1/books/arch-handbook/usb/chapter.xml
>@@ -668,7 +668,7 @@ This part is unclear, is it an unformatted code example?
> 
>     <para>Example: Firmware download Many devices that have been
>       developed are based on a general purpose processor with an
>-      additional USB core added to it.  Because the development of
>+      additional USB core added to it.  Since the development of
>       drivers and firmware for USB devices is still very new, many
>       devices require the downloading of the firmware after they have
>       been connected.</para>

Actions: View | Diff

Attachments on bug 252493: 221354 | 221358