docs/77774: [patch] Arch-Handbook, Remove contractions
Joel Dahl
joel at automatvapen.se
Sun Feb 20 13:20:01 UTC 2005
>Number: 77774
>Category: docs
>Synopsis: [patch] Arch-Handbook, Remove contractions
>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: Sun Feb 20 13:20:00 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator: Joel Dahl
>Release: FreeBSD 5.3-STABLE i386
>Organization:
>Environment:
System: FreeBSD dude.automatvapen.se 5.3-STABLE FreeBSD 5.3-STABLE #0: Thu Feb 10 12:46:21 CET 2005 joel at dude.automatvapen.se:/usr/obj/usr/src/sys/GENERIC i386
>Description:
The attached patch removes some contractions in the Arch-Handbook.
>How-To-Repeat:
>Fix:
--- cont_arch.diff begins here ---
Index: pccard/chapter.sgml
===================================================================
RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/arch-handbook/pccard/chapter.sgml,v
retrieving revision 1.9
diff -u -r1.9 chapter.sgml
--- pccard/chapter.sgml 11 Apr 2004 08:38:42 -0000 1.9
+++ pccard/chapter.sgml 20 Feb 2005 12:51:09 -0000
@@ -70,7 +70,7 @@
<para>Finally, some really low end devices do not contain
manufacturer identification at all. These devices require
that one matches them using the human readable CIS strings.
- While it would be nice if we didn't need this method as a
+ While it would be nice if we did not need this method as a
fallback, it is necessary for some very low end CD-ROM players
that are quite popular. This method should generally be
avoided, but a number of devices are listed in this section
@@ -89,7 +89,7 @@
them. This section is sorted in numerical order. The next
section has all of the products that are used by these
vendors, along with their product ID numbers and a description
- string. The description string typically isn't used (instead
+ string. The description string typically is not used (instead
we set the device's description based on the human readable
CIS, even if we match on the numeric version). These two
sections are then repeated for those devices that use the
@@ -112,16 +112,16 @@
that NETGEAR purchased cards from and the author of support
for those cards was unaware at the time that Netgear was using
someone else's id. These entries are fairly straightforward.
- There's the vendor keyword used to denote the kind of line
- that this is. There's the name of the vendor. This name will
+ There is the vendor keyword used to denote the kind of line
+ that this is. There is the name of the vendor. This name will
be repeated later in the pccarddevs file, as well as used in
the driver's match tables, so keep it short and a valid C
- identifier. There's a numeric ID, in hex, for the
+ identifier. There is a numeric ID, in hex, for the
manufacturer. Do not add IDs of the form
<literal>0xffffffff</literal> or <literal>0xffff</literal>
because these are reserved ids (the former is 'no id set'
while the latter is sometimes seen in extremely poor quality
- cards to try to indicate 'none). Finally there's a string
+ cards to try to indicate 'none). Finally there is a string
description of the company that makes the card. This string
is not used in FreeBSD for anything but commentary
purposes.</para>
@@ -139,10 +139,10 @@
product keyword. Then there is the vendor name, repeated from
above. This is followed by the product name, which is used by
the driver and should be a valid C identifier, but may also
- start with a number. There's then the product id for this
- card, in hex. As with the vendors, there's the same
+ start with a number. There is then the product id for this
+ card, in hex. As with the vendors, there is the same
convention for <literal>0xffffffff</literal> and
- <literal>0xffff</literal>. Finally, there's a string
+ <literal>0xffff</literal>. Finally, there is a string
description of the device itself. This string typically is
not used in FreeBSD, since FreeBSD's pccard bus driver will
construct a string from the human readable CIS entries, but it
@@ -176,9 +176,9 @@
strings are filtered by the program that generates
<filename>pccarddevs.h</filename> to replace &sp with a
real space. NULL entries mean that that part of the entry
- should be ignored. In the example I've picked, there's a bad
- entry. It shouldn't contain the version number in it unless
- that's critical for the operation of the card. Sometimes
+ should be ignored. In the example I have picked, there is a bad
+ entry. It should not contain the version number in it unless
+ that is critical for the operation of the card. Sometimes
vendors will have many different versions of the card in the
field that all work, in which case that information only makes
it harder for someone with a similar card to use it with
@@ -226,7 +226,7 @@
}</programlisting>
<para>Here we have a simple pccard probe routine that matches a
- few devices. As stated above, the name may vary (if it isn't
+ few devices. As stated above, the name may vary (if it is not
<function>foo_pccard_probe()</function> it will be
<function>foo_pccard_match()</function>). The function
<function>pccard_product_lookup()</function> is a generalized
@@ -268,7 +268,7 @@
First, one must obtain the identification information from the
device. The easiest way to do this is to insert the device
into a PC Card or CF slot and issue <command>devinfo
- -v</command>. You'll likely see something like:</para>
+ -v</command>. You will likely see something like:</para>
<programlisting> cbb1 pnpinfo vendor=0x104c device=0xac51 subvendor=0x1265 subdevice=0x0300 class=0x060700 at slot=10 function=1
cardbus1
@@ -288,7 +288,7 @@
<programlisting>vendor BUFFALO 0x026f BUFFALO (Melco Corporation)</programlisting>
- <para>so we're good there. Looking for an entry for this card,
+ <para>so we are good there. Looking for an entry for this card,
we do not find one. Instead we find:</para>
<programlisting>/* BUFFALO */
@@ -323,14 +323,14 @@
{ NULL }
};</programlisting>
- <para>Note that I've included a '<literal>+</literal>' in the
+ <para>Note that I have included a '<literal>+</literal>' in the
line before the line that I added, but that is simply to
highlight the line. Do not add it to the actual driver. Once
- you've added the line, you can recompile your kernel or module
+ you have added the line, you can recompile your kernel or module
and try to see if it recognizes the device. If it does and
- works, please submit a patch. If it doesn't work, please
+ works, please submit a patch. If it does not work, please
figure out what is needed to make it work and submit a patch.
- If it didn't recognize it at all, you have done something
+ If it did not recognize it at all, you have done something
wrong and should recheck each step.</para>
<para>If you are a FreeBSD src committer, and everything appears
@@ -352,11 +352,11 @@
<para>Many people send entries for new devices to the author
directly. Please do not do this. Please submit them as a PR
and send the author the PR number for his records. This makes
- sure that entries aren't lost. When submitting a PR, it is
+ sure that entries are not lost. When submitting a PR, it is
unnecessary to include the <filename>pccardevs.h</filename>
diffs in the patch, since those will be regenerated. It is
necessary to include a description of the device, as well as
- the patches to the client driver. If you don't know the name,
+ the patches to the client driver. If you do not know the name,
use OEM99 as the name, and the author will adjust OEM99
accordingly after investigation. Committers should not commit
OEM99, but instead find the highest OEM entry and commit one
Index: sound/chapter.sgml
===================================================================
RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/arch-handbook/sound/chapter.sgml,v
retrieving revision 1.7
diff -u -r1.7 chapter.sgml
--- sound/chapter.sgml 6 Aug 2003 23:48:03 -0000 1.7
+++ sound/chapter.sgml 20 Feb 2005 12:58:52 -0000
@@ -594,7 +594,7 @@
</callout>
<callout arearefs="co-mxset-return">
- <para>As the hardware levels probably won't match the
+ <para>As the hardware levels probably will not match the
input scale, and some rounding will occur, the routine
returns the actual level values (in range 0-100) as
shown.</para>
--- cont_arch.diff ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-doc
mailing list