* First pass at indexing.

* Add missing <literal> tag.

en_US.ISO8859-1/books/arch-handbook/newbus/chapter.sgml

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

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

@@ -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&amp;spTelesis&amp;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

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

@@ -21,6 +21,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
       to add support for new hardware.</para>
@@ -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>