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

Minor word smithing that I've had in my tree for a while. This

Browse source 
article could use further editing.
This commit is contained in:
Warner Losh 2012-03-19 04:14:40 +00:00
parent 4bca7fa226
commit c8817beb39
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=38606
1 changed files with 14 additions and 18 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -18,12 +18,8 @@
<sect1 id="pccard-adddev">
<title>Adding a device</title>
<para>The procedure for adding a new device to the list of
supported pccard devices has changed from the system used
through FreeBSD 4. In prior versions, editing a file in
<filename>/etc</filename> to list the device was necessary.
Starting in FreeBSD 5.0, devices drivers know what devices they
support. There is now a table of supported devices in the
<para>Devices drivers know what devices they
support. There is a table of supported devices in the
kernel that drivers use to attach to a device.</para>
<sect2 id="pccard-overview">
@ -39,15 +35,15 @@
design pattern to help the driver writer match devices to his
driver.</para>
<para>There is a widespread practice of one company developing a
reference design for a PC Card product and then selling this
design to other companies to market. Those companies refine
<para>OEMs manufacturers often develop a reference design for
a PC Card product sell this design to other companies to
market. Those companies refine
the design, market the product to their target audience or
geographic area and put their own name plate onto the card.
However, the refinements to the physical card typically are
very minor, if any changes are made at all. Often, however,
to strengthen their branding of their version of the card,
these vendors will place their company name in the human
The refinements to the physical card typically are
very minor, if any changes are made at all. However,
to strengthen their brand,
these vendors place their company name in the human
strings in the CIS space, but leave the manufacturer and
product ids unchanged.</para>
@ -55,9 +51,9 @@
<indexterm><primary>Linksys</primary></indexterm>
<indexterm><primary>D-Link</primary></indexterm>
<para>Because of the above practice, it is a smaller work load
for FreeBSD to use the numeric IDs. It also introduces some
minor complications into the process of adding IDs to the
<para>Because of this practice, FreeBSD drivers tend to
use the numeric IDs. Using numeric IDs and a centralized
database complicates adding IDs and support for cards to the
system. One must carefully check to see who really made the
card, especially when it appears that the vendor who made the
card from might already have a different manufacturer id
@ -68,7 +64,7 @@
devices will all have the same manufacturer and product
id.</para>
<para>The PC Card bus keeps its central database of card
<para>The PC Card bus code keeps a central database of card
information, but not which driver is associated with them, in
<filename>/sys/dev/pccard/pccarddevs</filename>. It also
provides a set of macros that allow one to easily construct
@ -80,7 +76,7 @@
that one matches them using the human readable CIS strings.
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
and ethernet cards. This method should generally be
avoided, but a number of devices are listed in this section
because they were added prior to the recognition of the
<acronym>OEM</acronym> nature of the PC Card business. When