* First pass at indexing.
* Add missing <literal> tag.
This commit is contained in:
parent
19e42de8a3
commit
0ccafc87cb
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=24454
3 changed files with 29 additions and 1 deletions
en_US.ISO8859-1/books/arch-handbook
|
@ -49,6 +49,9 @@
|
|||
<title>Device Drivers</title>
|
||||
<sect2>
|
||||
<title>Purpose of a Device Driver</title>
|
||||
|
||||
<indexterm><primary>device driver</primary></indexterm>
|
||||
<indexterm><primary>device driver</primary><secondary>introduction</secondary></indexterm>
|
||||
<para>A device driver is a software component which provides the
|
||||
interface between the kernel's generic view of a peripheral
|
||||
(e.g. disk, network adapter) and the actual implementation of the
|
||||
|
@ -69,6 +72,8 @@
|
|||
<listitem><para>pseudo-device drivers</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<indexterm><primary>block devices</primary></indexterm>
|
||||
|
||||
<para><emphasis>Block devices</emphasis> performed in way that used
|
||||
fixed size blocks [of data]. This type of driver depended on the
|
||||
so called <emphasis>buffer cache</emphasis>, which had the purpose
|
||||
|
@ -80,6 +85,9 @@
|
|||
|
||||
<sect2>
|
||||
<title>Character devices</title>
|
||||
|
||||
<indexterm><primary>character devices</primary></indexterm>
|
||||
|
||||
<para>However, in the versions of FreeBSD 4.0 and onward the
|
||||
distinction between block and character devices became non-existent.
|
||||
</para>
|
||||
|
@ -92,6 +100,9 @@
|
|||
Newbus, Busspace and the Resource Manager, an Explanation of the Possibilities
|
||||
-->
|
||||
<title>Overview of Newbus</title>
|
||||
|
||||
<indexterm><primary>Newbus</primary></indexterm>
|
||||
|
||||
<para><emphasis>Newbus</emphasis> is the implementation of a new bus
|
||||
architecture based on abstraction layers which saw its introduction in
|
||||
FreeBSD 3.0 when the Alpha port was imported into the source tree. It was
|
||||
|
|
|
@ -7,6 +7,9 @@
|
|||
<chapter id="pccard">
|
||||
<title>PC Card</title>
|
||||
|
||||
<indexterm><primary>PC Card</primary></indexterm>
|
||||
<indexterm><primary>CardBus</primary></indexterm>
|
||||
|
||||
<para>This chapter will talk about the FreeBSD mechanisms for
|
||||
writing a device driver for a PC Card or CardBus device. However,
|
||||
at the present time, it just documents how to add a driver to an
|
||||
|
@ -26,6 +29,7 @@
|
|||
<sect2 id="pccard-overview">
|
||||
<title>Overview</title>
|
||||
|
||||
<indexterm><primary>CIS</primary></indexterm>
|
||||
<para>PC Cards are identified in one of two ways, both based on
|
||||
information in the <acronym>CIS</acronym> of the card. The
|
||||
first method is to use numeric manufacturer and product
|
||||
|
@ -47,6 +51,10 @@
|
|||
strings in the CIS space, but leave the manufacturer and
|
||||
product ids unchanged.</para>
|
||||
|
||||
<indexterm><primary>NetGear</primary></indexterm>
|
||||
<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
|
||||
|
@ -195,6 +203,8 @@ product ALLIEDTELESIS WR211PCM { "Allied&spTelesis&spK.K.", "WR211PCM",
|
|||
<sect2 id="pccard-probe">
|
||||
<title>Sample probe routine</title>
|
||||
|
||||
<indexterm><primary>PC Card</primary><secondary>probe</secondary></indexterm>
|
||||
|
||||
<para>To understand how to add a device to the list of supported
|
||||
devices, one must understand the probe and/or match routines
|
||||
that many drivers have. It is complicated a little in FreeBSD
|
||||
|
|
|
@ -20,6 +20,8 @@
|
|||
|
||||
<sect1 id="oss-intro">
|
||||
<title>Introduction</title>
|
||||
|
||||
<indexterm><primary>sound subsystem</primary></indexterm>
|
||||
|
||||
<para>The FreeBSD sound subsystem cleanly separates generic sound
|
||||
handling issues from device-specific ones. This makes it easier
|
||||
|
@ -28,6 +30,8 @@
|
|||
<para>The &man.pcm.4; framework is the central piece of the sound
|
||||
subsystem. It mainly implements the following elements:</para>
|
||||
|
||||
<indexterm><primary>system call interface</primary></indexterm>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>A system call interface (read, write, ioctls) to
|
||||
|
@ -117,6 +121,7 @@
|
|||
DRIVER_MODULE(snd_xxxpci, pci, xxx_driver, pcm_devclass, 0, 0);
|
||||
MODULE_DEPEND(snd_xxxpci, snd_pcm, PCM_MINVER, PCM_PREFVER,PCM_MAXVER);</programlisting>
|
||||
|
||||
<indexterm><primary>device drivers</primary><secondary>sound</secondary></indexterm>
|
||||
<para>Most sound drivers need to store additional private
|
||||
information about their device. A private data structure is
|
||||
usually allocated in the attach routine. Its address is
|
||||
|
@ -587,7 +592,7 @@
|
|||
|
||||
<calloutlist>
|
||||
<callout arearefs="co-mxset-params">
|
||||
<para>The device is specified as a SOUND_MIXER_XXX
|
||||
<para>The device is specified as a <literal>SOUND_MIXER_XXX</literal>
|
||||
value</para> <para>The volume values are specified in
|
||||
range [0-100]. A value of zero should mute the
|
||||
device.</para>
|
||||
|
@ -652,6 +657,8 @@
|
|||
<sect2>
|
||||
<title>The AC97 interface</title>
|
||||
|
||||
<indexterm><primary>AC97</primary></indexterm>
|
||||
|
||||
<para>The <emphasis>AC97</emphasis> interface is implemented
|
||||
by drivers with an AC97 codec. It only has three methods:</para>
|
||||
|
||||
|
|
Loading…
Reference in a new issue