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 <para>Finally, some really low end devices do not contain
manufacturer identification at all. These devices require manufacturer identification at all. These devices require
that one matches them using the human readable CIS strings. 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 fallback, it is necessary for some very low end CD-ROM players
that are quite popular. This method should generally be that are quite popular. This method should generally be
avoided, but a number of devices are listed in this section 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 them. This section is sorted in numerical order. The next
section has all of the products that are used by these section has all of the products that are used by these
vendors, along with their product ID numbers and a description 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 we set the device's description based on the human readable
CIS, even if we match on the numeric version). These two CIS, even if we match on the numeric version). These two
sections are then repeated for those devices that use the 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 that NETGEAR purchased cards from and the author of support
for those cards was unaware at the time that Netgear was using for those cards was unaware at the time that Netgear was using
someone else's id. These entries are fairly straightforward. someone else's id. These entries are fairly straightforward.
There's the vendor keyword used to denote the kind of line There is the vendor keyword used to denote the kind of line
that this is. There's the name of the vendor. This name will 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 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 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 manufacturer. Do not add IDs of the form
<literal>0xffffffff</literal> or <literal>0xffff</literal> <literal>0xffffffff</literal> or <literal>0xffff</literal>
because these are reserved ids (the former is 'no id set' because these are reserved ids (the former is 'no id set'
while the latter is sometimes seen in extremely poor quality 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 description of the company that makes the card. This string
is not used in FreeBSD for anything but commentary is not used in FreeBSD for anything but commentary
purposes.</para> purposes.</para>
@ -139,10 +139,10 @@ product ARCHOS ARC_ATAPI 0x0043 MiniCD</programlisting>
product keyword. Then there is the vendor name, repeated from product keyword. Then there is the vendor name, repeated from
above. This is followed by the product name, which is used by above. This is followed by the product name, which is used by
the driver and should be a valid C identifier, but may also the driver and should be a valid C identifier, but may also
start with a number. There's then the product id for this start with a number. There is then the product id for this
card, in hex. As with the vendors, there's the same card, in hex. As with the vendors, there is the same
convention for <literal>0xffffffff</literal> and 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 description of the device itself. This string typically is
not used in FreeBSD, since FreeBSD's pccard bus driver will not used in FreeBSD, since FreeBSD's pccard bus driver will
construct a string from the human readable CIS entries, but it 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 strings are filtered by the program that generates
<filename>pccarddevs.h</filename> to replace &amp;sp with a <filename>pccarddevs.h</filename> to replace &amp;sp with a
real space. NULL entries mean that that part of the entry real space. NULL entries mean that that part of the entry
should be ignored. In the example I've picked, there's a bad should be ignored. In the example I have picked, there is a bad
entry. It shouldn't contain the version number in it unless entry. It should not contain the version number in it unless
that's critical for the operation of the card. Sometimes that is critical for the operation of the card. Sometimes
vendors will have many different versions of the card in the vendors will have many different versions of the card in the
field that all work, in which case that information only makes field that all work, in which case that information only makes
it harder for someone with a similar card to use it with it harder for someone with a similar card to use it with
@ -226,7 +226,7 @@ wi_pccard_probe(dev)
}</programlisting> }</programlisting>
<para>Here we have a simple pccard probe routine that matches a <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_probe()</function> it will be
<function>foo_pccard_match()</function>). The function <function>foo_pccard_match()</function>). The function
<function>pccard_product_lookup()</function> is a generalized <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 First, one must obtain the identification information from the
device. The easiest way to do this is to insert the device device. The easiest way to do this is to insert the device
into a PC Card or CF slot and issue <command>devinfo 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 <programlisting> cbb1 pnpinfo vendor=0x104c device=0xac51 subvendor=0x1265 subdevice=0x0300 class=0x060700 at slot=10 function=1
cardbus1 cardbus1
@ -288,7 +288,7 @@ wi_pccard_probe(dev)
<programlisting>vendor BUFFALO 0x026f BUFFALO (Melco Corporation)</programlisting> <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> we do not find one. Instead we find:</para>
<programlisting>/* BUFFALO */ <programlisting>/* BUFFALO */
@ -323,14 +323,14 @@ product BUFFALO WLI_CF_S11G 0x030b BUFFALO AirStation 11Mbps CF WLAN</programlis
{ NULL } { NULL }
};</programlisting> };</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 line before the line that I added, but that is simply to
highlight the line. Do not add it to the actual driver. Once 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 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. 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> wrong and should recheck each step.</para>
<para>If you are a FreeBSD src committer, and everything appears <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 <para>Many people send entries for new devices to the author
directly. Please do not do this. Please submit them as a PR directly. Please do not do this. Please submit them as a PR
and send the author the PR number for his records. This makes 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> unnecessary to include the <filename>pccardevs.h</filename>
diffs in the patch, since those will be regenerated. It is diffs in the patch, since those will be regenerated. It is
necessary to include a description of the device, as well as 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 use OEM99 as the name, and the author will adjust OEM99
accordingly after investigation. Committers should not commit accordingly after investigation. Committers should not commit
OEM99, but instead find the highest OEM entry and commit one 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>
<callout arearefs="co-mxset-return"> <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 input scale, and some rounding will occur, the routine
returns the actual level values (in range 0-100) as returns the actual level values (in range 0-100) as
shown.</para> shown.</para>