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

Remove more contractions.

Browse source 
PR:		docs/77774
Submitted by:	Joel Dahl <joel@automatvapen.se>
This commit is contained in:
Simon L. B. Nielsen 2005-02-20 14:14:45 +00:00
parent a01576d36a
commit e822759e45
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=23832
2 changed files with 22 additions and 22 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

42
en_US.ISO8859-1/books/arch-handbook/pccard/chapter.sgml
View file

@ -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 @@ vendor SANDISK 0x0045 Sandisk Corporation</programlisting>
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 ARCHOS ARC_ATAPI 0x0043 MiniCD</programlisting>
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 @@ product ALLIEDTELESIS WR211PCM { "Allied&amp;spTelesis&amp;spK.K.", "WR211PCM",
strings are filtered by the program that generates
<filename>pccarddevs.h</filename> to replace &amp;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 @@ wi_pccard_probe(dev)
}</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 @@ wi_pccard_probe(dev)
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 @@ wi_pccard_probe(dev)
<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 @@ product BUFFALO WLI_CF_S11G 0x030b BUFFALO AirStation 11Mbps CF WLAN</programlis
{ 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 @@ product BUFFALO WLI_CF_S11G 0x030b BUFFALO AirStation 11Mbps CF WLAN</programlis
<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

2
en_US.ISO8859-1/books/arch-handbook/sound/chapter.sgml
View file

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