FreeBSD Bugzilla – Attachment 221358 Details for
Bug 252493
Stop using "Because" in sentence fragments
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Help
|
New Account
|
Log In
Remember
[x]
|
Forgot Password
Login:
[x]
[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:
Corrected patch
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—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>
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
Attachments on
bug 252493
:
221354
| 221358