12535 lines
237 KiB
HTML
12535 lines
237 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Linux Loadable Kernel Module HOWTO</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
|
|
><BODY
|
|
CLASS="ARTICLE"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="ARTICLE"
|
|
><DIV
|
|
CLASS="TITLEPAGE"
|
|
><H1
|
|
CLASS="TITLE"
|
|
><A
|
|
NAME="AEN2"
|
|
></A
|
|
>Linux Loadable Kernel Module HOWTO</H1
|
|
><H3
|
|
CLASS="AUTHOR"
|
|
><A
|
|
NAME="AEN4"
|
|
>Bryan Henderson</A
|
|
></H3
|
|
><P
|
|
CLASS="PUBDATE"
|
|
>2006-09-24<BR></P
|
|
><DIV
|
|
CLASS="REVHISTORY"
|
|
><TABLE
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TH
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
COLSPAN="3"
|
|
><B
|
|
>Revision History</B
|
|
></TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revision v1.09</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>2006-09-24</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revised by: bjh</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
COLSPAN="3"
|
|
>Fix typos.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revision v1.08</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>2006-03-03</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revised by: bjh</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
COLSPAN="3"
|
|
>Add copyright information.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revision v1.07</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>2005-07-20</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revised by: bjh</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
COLSPAN="3"
|
|
>Add some 2.6 info and disclaimers.
|
|
Update references to Linux Device Drivers
|
|
book, Linux Kernel Module Programming Guide.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revision v1.06</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>2005-01-12</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revised by: bjh</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
COLSPAN="3"
|
|
>Cover Linux 2.6 briefly.
|
|
Update hello.c and reference to Lkmpg.
|
|
Add information about perils of unloading.
|
|
Mention dmesg as way to see kernel messages.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revision v1.05</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>2004-01-05</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revised by: bjh</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
COLSPAN="3"
|
|
>Add information on module.h and -DMODULE.
|
|
Fix tldb.org to tldp.org.
|
|
Add information on kallsyms.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revision v1.04</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>2003-10-10</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revised by: bjh</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
COLSPAN="3"
|
|
>Fix typo: AHA154x should be AHA152x
|
|
Add information on what module names the kernel module loader
|
|
calls for. Add information on what an LKM does when you first
|
|
load it. Add information on loop module. Change linuxdoc.org
|
|
to tldp.org.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revision v1.03</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>2003-07-03</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revised by: bjh</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
COLSPAN="3"
|
|
>Update on kernels that don't load into vmalloc space.
|
|
Add explanation of "deleted" state of an LKM.
|
|
Explain GPLONLY.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revision v1.02</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>2002-05-21</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revised by: bjh</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
COLSPAN="3"
|
|
>Correct explanation of symbol versioning.
|
|
Correct author of Linux Device Drivers.
|
|
Add info about memory allocation penalty of LKM vs bound-in.
|
|
Add LKM-to-LKM symbol matching requirement.
|
|
Add open source licensing issue in LKM symbol resolution.
|
|
Add SMP symbol versioning info.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revision v1.01</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>2001-08-18</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revised by: bjh</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
COLSPAN="3"
|
|
>Add material on various features created in the last few
|
|
years: kernel module loader, ksymoops symbols,
|
|
kernel-version-dependent LKM file location.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revision v1.00</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>2001-06-14</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
>Revised by: bjh</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
COLSPAN="3"
|
|
>Initial release.</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
><DIV
|
|
CLASS="ABSTRACT"
|
|
><A
|
|
NAME="AEN62"
|
|
></A
|
|
><P
|
|
></P
|
|
><P
|
|
>This is the HOWTO for Linux loadable kernel modules (LKMs). It
|
|
explains what they are and how to use and create them. It also
|
|
includes documentation of parameters and other details of use of some
|
|
particular modules.</P
|
|
><P
|
|
></P
|
|
></DIV
|
|
></DIV
|
|
><HR></DIV
|
|
><DIV
|
|
CLASS="TOC"
|
|
><DL
|
|
><DT
|
|
><B
|
|
>Table of Contents</B
|
|
></DT
|
|
><DT
|
|
>1. <A
|
|
HREF="#AEN64"
|
|
>Preface</A
|
|
></DT
|
|
><DT
|
|
>2. <A
|
|
HREF="#AEN73"
|
|
>Introduction to Linux Loadable Kernel Modules</A
|
|
></DT
|
|
><DD
|
|
><DL
|
|
><DT
|
|
>2.1. <A
|
|
HREF="#AEN77"
|
|
>Terminology</A
|
|
></DT
|
|
><DT
|
|
>2.2. <A
|
|
HREF="#AEN90"
|
|
>History of Loadable Kernel Modules</A
|
|
></DT
|
|
><DT
|
|
>2.3. <A
|
|
HREF="#THECASE"
|
|
>The Case For Loadable Kernel Modules</A
|
|
></DT
|
|
><DT
|
|
>2.4. <A
|
|
HREF="#AEN107"
|
|
>What LKMs Can't Do</A
|
|
></DT
|
|
><DT
|
|
>2.5. <A
|
|
HREF="#AEN110"
|
|
>What LKMs Are Used For</A
|
|
></DT
|
|
></DL
|
|
></DD
|
|
><DT
|
|
>3. <A
|
|
HREF="#AEN126"
|
|
>Making Loadable Kernel Modules</A
|
|
></DT
|
|
><DT
|
|
>4. <A
|
|
HREF="#AEN146"
|
|
>LKM Utilities</A
|
|
></DT
|
|
><DT
|
|
>5. <A
|
|
HREF="#AEN197"
|
|
>How To Insert And Remove LKMs</A
|
|
></DT
|
|
><DD
|
|
><DL
|
|
><DT
|
|
>5.1. <A
|
|
HREF="#AEN248"
|
|
>Could Not Find Kernel Version...</A
|
|
></DT
|
|
><DT
|
|
>5.2. <A
|
|
HREF="#AEN269"
|
|
>What Happens When An LKM Loads</A
|
|
></DT
|
|
><DT
|
|
>5.3. <A
|
|
HREF="#INTELLIGENT"
|
|
>Intelligent Loading Of LKMs - Modprobe</A
|
|
></DT
|
|
><DT
|
|
>5.4. <A
|
|
HREF="#AUTOLOAD"
|
|
>Automatic LKM Loading and Unloading</A
|
|
></DT
|
|
><DT
|
|
>5.5. <A
|
|
HREF="#PROCMODULES"
|
|
>/proc/modules</A
|
|
></DT
|
|
><DT
|
|
>5.6. <A
|
|
HREF="#MODLOCATION"
|
|
>Where Are My LKM Files On My System?</A
|
|
></DT
|
|
></DL
|
|
></DD
|
|
><DT
|
|
>6. <A
|
|
HREF="#BASEKERNCOMPAT"
|
|
>Unresolved Symbols</A
|
|
></DT
|
|
><DD
|
|
><DL
|
|
><DT
|
|
>6.1. <A
|
|
HREF="#AEN502"
|
|
>Some LKMs Prerequire Other LKMs</A
|
|
></DT
|
|
><DT
|
|
>6.2. <A
|
|
HREF="#AEN507"
|
|
>An LKM Must Match The Base Kernel</A
|
|
></DT
|
|
><DT
|
|
>6.3. <A
|
|
HREF="#MULTIPLEKERNELS"
|
|
>If You Run Multiple Kernels</A
|
|
></DT
|
|
><DT
|
|
>6.4. <A
|
|
HREF="#AEN567"
|
|
>SMP symbols</A
|
|
></DT
|
|
><DT
|
|
>6.5. <A
|
|
HREF="#AEN574"
|
|
>You Are Not Licensed To Access The Symbol</A
|
|
></DT
|
|
><DT
|
|
>6.6. <A
|
|
HREF="#AEN586"
|
|
>An LKM Must Match Prerequisite LKMs</A
|
|
></DT
|
|
></DL
|
|
></DD
|
|
><DT
|
|
>7. <A
|
|
HREF="#AEN589"
|
|
>How To Boot Without A Disk Device Driver</A
|
|
></DT
|
|
><DT
|
|
>8. <A
|
|
HREF="#PARM"
|
|
>About Module Parameters</A
|
|
></DT
|
|
><DT
|
|
>9. <A
|
|
HREF="#AEN615"
|
|
>Persistent Data</A
|
|
></DT
|
|
><DT
|
|
>10. <A
|
|
HREF="#AEN627"
|
|
>Technical Details</A
|
|
></DT
|
|
><DD
|
|
><DL
|
|
><DT
|
|
>10.1. <A
|
|
HREF="#HOWTHEYWORK"
|
|
>How They Work</A
|
|
></DT
|
|
><DT
|
|
>10.2. <A
|
|
HREF="#MODINFO"
|
|
>The .modinfo Section</A
|
|
></DT
|
|
><DT
|
|
>10.3. <A
|
|
HREF="#AEN712"
|
|
>The __ksymtab And .kstrtab Sections</A
|
|
></DT
|
|
><DT
|
|
>10.4. <A
|
|
HREF="#AEN722"
|
|
>Ksymoops Symbols</A
|
|
></DT
|
|
><DT
|
|
>10.5. <A
|
|
HREF="#AEN782"
|
|
>Other Symbols</A
|
|
></DT
|
|
><DT
|
|
>10.6. <A
|
|
HREF="#AEN793"
|
|
>Debugging Symbols</A
|
|
></DT
|
|
><DT
|
|
>10.7. <A
|
|
HREF="#MEMALLOC"
|
|
>Memory Allocation For Loading</A
|
|
></DT
|
|
><DT
|
|
>10.8. <A
|
|
HREF="#AEN830"
|
|
>Linux internals</A
|
|
></DT
|
|
></DL
|
|
></DD
|
|
><DT
|
|
>11. <A
|
|
HREF="#AEN839"
|
|
>Writing Your Own Loadable Kernel Module</A
|
|
></DT
|
|
><DD
|
|
><DL
|
|
><DT
|
|
>11.1. <A
|
|
HREF="#AEN846"
|
|
>Simpler hello.c</A
|
|
></DT
|
|
><DT
|
|
>11.2. <A
|
|
HREF="#AEN870"
|
|
>Using the Kernel Build System</A
|
|
></DT
|
|
><DT
|
|
>11.3. <A
|
|
HREF="#AEN876"
|
|
>Rubini et al: Linux Device Drivers</A
|
|
></DT
|
|
><DT
|
|
>11.4. <A
|
|
HREF="#USECOUNT"
|
|
>Module Use Counts</A
|
|
></DT
|
|
></DL
|
|
></DD
|
|
><DT
|
|
>12. <A
|
|
HREF="#LINUXVERSIONS"
|
|
>Differences Between Versions Of Linux</A
|
|
></DT
|
|
><DD
|
|
><DL
|
|
><DT
|
|
>12.1. <A
|
|
HREF="#AEN911"
|
|
>Linux 2.4 - Linux 2.6</A
|
|
></DT
|
|
></DL
|
|
></DD
|
|
><DT
|
|
>13. <A
|
|
HREF="#COPYRIGHT"
|
|
>Copyright Considerations With LKMs</A
|
|
></DT
|
|
><DT
|
|
>14. <A
|
|
HREF="#AEN973"
|
|
>Related Documentation</A
|
|
></DT
|
|
><DT
|
|
>15. <A
|
|
HREF="#INDIVIDUAL"
|
|
>Individual Modules</A
|
|
></DT
|
|
><DD
|
|
><DL
|
|
><DT
|
|
>15.1. <A
|
|
HREF="#AEN985"
|
|
>Executable Interpreters</A
|
|
></DT
|
|
><DT
|
|
>15.2. <A
|
|
HREF="#AEN1016"
|
|
>Block Device Drivers</A
|
|
></DT
|
|
><DT
|
|
>15.3. <A
|
|
HREF="#SCSI"
|
|
>SCSI Drivers</A
|
|
></DT
|
|
><DT
|
|
>15.4. <A
|
|
HREF="#AEN1555"
|
|
>Network Device Drivers</A
|
|
></DT
|
|
><DT
|
|
>15.5. <A
|
|
HREF="#AEN2553"
|
|
>CDROM Device Drivers</A
|
|
></DT
|
|
><DT
|
|
>15.6. <A
|
|
HREF="#AEN2694"
|
|
>Filesystem Drivers</A
|
|
></DT
|
|
><DT
|
|
>15.7. <A
|
|
HREF="#AEN2813"
|
|
>Miscellaneous Device Driver</A
|
|
></DT
|
|
><DT
|
|
>15.8. <A
|
|
HREF="#AEN2821"
|
|
>Serial Device Drivers</A
|
|
></DT
|
|
><DT
|
|
>15.9. <A
|
|
HREF="#AEN2868"
|
|
>Parallel Device Drivers</A
|
|
></DT
|
|
><DT
|
|
>15.10. <A
|
|
HREF="#AEN2877"
|
|
>Bus Mouse Device Drivers</A
|
|
></DT
|
|
><DT
|
|
>15.11. <A
|
|
HREF="#AEN2907"
|
|
>Tape Device Drivers</A
|
|
></DT
|
|
><DT
|
|
>15.12. <A
|
|
HREF="#AEN2955"
|
|
>Watchdog Timers</A
|
|
></DT
|
|
><DT
|
|
>15.13. <A
|
|
HREF="#AEN2979"
|
|
>Sound Device Drivers</A
|
|
></DT
|
|
></DL
|
|
></DD
|
|
><DT
|
|
>16. <A
|
|
HREF="#AEN2986"
|
|
>Maintenance Of This Document</A
|
|
></DT
|
|
><DT
|
|
>17. <A
|
|
HREF="#HISTORY"
|
|
>History</A
|
|
></DT
|
|
><DT
|
|
>18. <A
|
|
HREF="#AEN2997"
|
|
>Copyright</A
|
|
></DT
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN64"
|
|
></A
|
|
>1. Preface</H1
|
|
><P
|
|
>Copyright and license information, as well as credits, are at the end
|
|
of this document.</P
|
|
><P
|
|
>This HOWTO is maintained by Bryan Henderson, bryanh@giraffe-data.com.
|
|
You can get the current version of this HOWTO from <A
|
|
HREF="http://tldp.org"
|
|
TARGET="_top"
|
|
>the Linux Documentation Project</A
|
|
>.</P
|
|
><P
|
|
>This document is mainly geared toward Linux 2.4. It covers
|
|
secondarily earlier Linux. It covers newer Linux only partially, but
|
|
the author's goal to cover it completely in a future release. See
|
|
in particular <A
|
|
HREF="#LINUXVERSIONS"
|
|
>Section 12</A
|
|
>.
|
|
|
|
|
|
The
|
|
subject changed quite a bit over the course of Linux 2.5 releases, and
|
|
this document ignores 2.5, since the 2.5 releases were not considered
|
|
production releases. Instead, the document treats all the changes in
|
|
2.5 releases as if they were new with Linux 2.6.</P
|
|
><P
|
|
>See <A
|
|
HREF="#HISTORY"
|
|
>Section 17</A
|
|
> for a history of the document.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><HR><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN73"
|
|
></A
|
|
>2. Introduction to Linux Loadable Kernel Modules</H1
|
|
><P
|
|
>If you want to add code to a Linux kernel, the most basic way to do
|
|
that is to add some source files to the kernel source tree and
|
|
recompile the kernel. In fact, the kernel configuration process
|
|
consists mainly of choosing which files to include in the kernel to be
|
|
compiled.</P
|
|
><P
|
|
>But you can also add code to the Linux kernel while it is running. A
|
|
chunk of code that you add in this way is called a loadable kernel
|
|
module. These modules can do lots of things, but they typically are
|
|
one of three things: 1) device drivers; 2) filesystem drivers; 3)
|
|
system calls. The kernel isolates certain functions, including these,
|
|
especially well so they don't have to be intricately wired into the
|
|
rest of the kernel.</P
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN77"
|
|
></A
|
|
>2.1. Terminology</H2
|
|
><P
|
|
>Loadable kernel modules are often called just kernel modules or just
|
|
modules, but those are rather misleading terms because there are lots
|
|
of kinds of modules in the world and various pieces built into the
|
|
base kernel can easily be called modules. We use the term loadable
|
|
kernel module or LKM for the particular kinds of modules this HOWTO is
|
|
about.</P
|
|
><P
|
|
>Some people think of LKMs as outside of the kernel. They speak of
|
|
LKMs communicating with the kernel. This is a mistake; LKMs (when
|
|
loaded) are very much part of the kernel. The correct term for the
|
|
part of the kernel that is bound into the image that you boot, i.e.
|
|
all of the kernel <EM
|
|
>except</EM
|
|
> the LKMs, is "base
|
|
kernel." LKMs communicate with the base kernel.</P
|
|
><P
|
|
>In some other operating systems, the equivalent of a Linux LKM is
|
|
called a "kernel extension."</P
|
|
><P
|
|
>Now what is "Linux"? Well, first of all, the name is used for
|
|
two entirely different things, and only one of them is really relevant
|
|
here:
|
|
<P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
>The kernel and related items distributed as a package by Linus Torvalds.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>A class of operating systems that traditionally are based on the Linux
|
|
kernel.</P
|
|
></LI
|
|
></OL
|
|
></P
|
|
><P
|
|
>Only the first of these is really useful in discussing LKMs. But even
|
|
choosing this definition, people are often confused when it comes to
|
|
LKMs. Is an LKM part of Linux or not? Though an LKM is always part
|
|
of the kernel, it is part of Linux if it is distributed in the Linux
|
|
kernel package, and not otherwise. Thus, if you have loaded into your
|
|
kernel a device driver LKM that came with your device, you can't,
|
|
strictly speaking, say that your kernel is Linux. Rather, it's a
|
|
slight extension of Linux.
|
|
|
|
As you might expect, it is commonplace to use the name "Linux"
|
|
approximately -- Lots of variations on Linux are in use and are widely
|
|
distributed, and referred to as "Linux." In this document,
|
|
though, we will stick to the strictest definition in the interest of
|
|
clarity. </P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN90"
|
|
></A
|
|
>2.2. History of Loadable Kernel Modules</H2
|
|
><P
|
|
>LKMs did not exist in Linux in the beginning. Anything we use an LKM
|
|
for today was built into the base kernel at kernel build time instead.
|
|
LKMs have been around at least since Linux 1.2 (1995).</P
|
|
><P
|
|
>Device drivers and such were always quite modular, though. When LKMs
|
|
were invented, only a small amount of work was needed on these modules
|
|
to make them buildable as LKMs. However, it had to be done on each
|
|
and every one, so it took some time. Since about 2000, virtually
|
|
everything that makes sense as an LKM has at least had the option of
|
|
being an LKM.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="THECASE"
|
|
></A
|
|
>2.3. The Case For Loadable Kernel Modules</H2
|
|
><P
|
|
>You often have a choice between putting a module into the kernel by
|
|
loading it as an LKM or binding it into the base kernel. LKMs have a
|
|
lot of advantages over binding into the base kernel and I recommend
|
|
them wherever possible.</P
|
|
><P
|
|
>One advantage is that you don't have to rebuild your kernel as often.
|
|
This saves you time and spares you the possibility of introducing an
|
|
error in rebuilding and reinstalling the base kernel. Once you have a
|
|
working base kernel, it is good to leave it untouched as long as
|
|
possible.</P
|
|
><P
|
|
>Another advantage is that LKMs help you diagnose system problems. A
|
|
bug in a device driver which is bound into the kernel can stop your
|
|
system from booting at all. And it can be really hard to tell which
|
|
part of the base kernel caused the trouble. If the same device driver
|
|
is an LKM, though, the base kernel is up and running before the device
|
|
driver even gets loaded. If your system dies after the base kernel is
|
|
up and running, it's an easy matter to track the problem down to the
|
|
trouble-making device driver and just not load that device driver
|
|
until you fix the problem.</P
|
|
><P
|
|
>LKMs can save you memory, because you have to have them loaded
|
|
only when you're actually using them. All parts of the base kernel stay
|
|
loaded all the time. And in real storage, not just virtual storage.</P
|
|
><P
|
|
>LKMs are much faster to maintain and debug. What would require a full
|
|
reboot to do with a filesystem driver built into the kernel, you can
|
|
do with a few quick commands with LKMs. You can try out different
|
|
parameters or even change the code repeatedly in rapid succession,
|
|
without waiting for a boot.</P
|
|
><P
|
|
>LKMs are not slower, by the way, than base kernel modules. Calling
|
|
either one is simply a branch to the memory location where it resides.
|
|
<A
|
|
NAME="AEN102"
|
|
HREF="#FTN.AEN102"
|
|
><SPAN
|
|
CLASS="footnote"
|
|
>[1]</SPAN
|
|
></A
|
|
></P
|
|
><P
|
|
>Sometimes you <EM
|
|
>have</EM
|
|
> to build something into the
|
|
base kernel instead of making it an LKM. Anything that is necessary
|
|
to get the system up far enough to load LKMs must obviously be built
|
|
into the base kernel. For example, the driver for the disk drive that
|
|
contains the root filesystem must be built into the base kernel.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN107"
|
|
></A
|
|
>2.4. What LKMs Can't Do</H2
|
|
><P
|
|
>There is a tendency to think of LKMs like user space programs. They
|
|
do share a lot of their properties, but LKMs are definitely not user
|
|
space programs. They are part of the kernel. As such, they have free
|
|
run of the system and can easily crash it. </P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN110"
|
|
></A
|
|
>2.5. What LKMs Are Used For</H2
|
|
><P
|
|
>There are six main things LKMs are used for:
|
|
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>Device drivers. A device driver is designed for a specific piece of
|
|
hardware. The kernel uses it to communicate with that piece of
|
|
hardware without having to know any details of how the hardware works.
|
|
For example, there is a device driver for ATA disk drives. There is
|
|
one for NE2000 compatible Ethernet cards. To use any device, the
|
|
kernel must contain a device driver for it.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Filesystem drivers. A filesystem driver interprets the contents of a
|
|
filesystem (which is typically the contents of a disk drive) as files
|
|
and directories and such. There are lots of different ways of storing
|
|
files and directories and such on disk drives, on network servers, and
|
|
in other ways. For each way, you need a filesystem driver. For
|
|
example, there's a filesystem driver for the ext2 filesystem type used
|
|
almost universally on Linux disk drives. There is one for the MS-DOS
|
|
filesystem too, and one for NFS.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>System calls. User space programs use system calls to get services
|
|
from the kernel. For example, there are system calls to read a file,
|
|
to create a new process, and to shut down the system. Most system
|
|
calls are integral to the system and very standard, so are always
|
|
built into the base kernel (no LKM option). But you can invent a
|
|
system call of your own and install it as an LKM. Or you can decide
|
|
you don't like the way Linux does something and override an existing
|
|
system call with an LKM of your own.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Network drivers. A network driver interprets a network protocol. It
|
|
feeds and consumes data streams at various layers of the kernel's
|
|
networking function. For example, if you want an IPX link in your
|
|
network, you would use the IPX driver.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>TTY line disciplines. These are essentially augmentations of device
|
|
drivers for terminal devices.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Executable interpreters. An executable interpreter loads and runs an
|
|
executable. Linux is designed to be able to run executables in
|
|
various formats, and each must have its own executable interpreter.</P
|
|
></LI
|
|
></UL
|
|
></P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><HR><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN126"
|
|
></A
|
|
>3. Making Loadable Kernel Modules</H1
|
|
><P
|
|
>An LKM lives in a single ELF object file (normally named like
|
|
"serial.o"). You typically keep all your LKM object files in a
|
|
particular directory (near your base kernel image makes sense). When
|
|
you use the <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> program to insert an LKM into
|
|
the kernel, you give the name of that object file.</P
|
|
><P
|
|
>For the LKMs that are part of Linux, you build them as part of the
|
|
same kernel build process that generates the base kernel image. See
|
|
the README file in the Linux source tree. In short, after you make
|
|
the base kernel image with a command such as
|
|
<B
|
|
CLASS="COMMAND"
|
|
>make zImage</B
|
|
>,
|
|
you will make all the LKMs with the command
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>make modules </PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>This results in a bunch of LKM object files (*.o) throughout the Linux
|
|
source tree. (In older versions of Linux, there would be symbolic
|
|
links in the <TT
|
|
CLASS="LITERAL"
|
|
>modules</TT
|
|
> directory of the Linux source
|
|
tree pointing to all those LKM object files). These LKMs are ready to
|
|
load, but you probably want to install them in some appropriate
|
|
directory. The conventional place is described in <A
|
|
HREF="#MODLOCATION"
|
|
>Section 5.6</A
|
|
>. The command
|
|
<B
|
|
CLASS="COMMAND"
|
|
>make modules_install</B
|
|
>
|
|
will copy them all over to the conventional locations.</P
|
|
><P
|
|
>Part of configuring the Linux kernel (at build time) is choosing which
|
|
parts of the kernel to bind into the base kernel and which parts to
|
|
generate as separate LKMs. In the basic question-and-answer
|
|
configuration (<B
|
|
CLASS="COMMAND"
|
|
>make config</B
|
|
>), you are asked, for
|
|
each optional part of the kernel, whether you want it bound into the
|
|
kernel (a "Y" response), created as an LKM (an "M" response), or just
|
|
skipped completely (an "N" response). Other configuration methods are
|
|
similar.</P
|
|
><P
|
|
>As explained in <A
|
|
HREF="#THECASE"
|
|
>Section 2.3</A
|
|
>, you should have
|
|
only the bare minimum bound into the base kernel. And only skip
|
|
completely the parts that you're sure you'll never want. There is
|
|
very little to lose by building an LKM that you won't use. Some
|
|
compile time, some disk space, some chance of a problem in the code
|
|
killing the kernel build. That's it.</P
|
|
><P
|
|
>As part of the configuration dialog you also must choose whether to
|
|
use symbol versioning or not. This choice affects building both the
|
|
base kernel and the LKMs and it is crucial you get it right. See
|
|
<A
|
|
HREF="#BASEKERNCOMPAT"
|
|
>Section 6</A
|
|
>.</P
|
|
><P
|
|
>LKMs that are not part of Linux (i.e. not distributed with the Linux kernel)
|
|
have their own build procedures which I will not cover. The goal of any
|
|
such procedure, though, is always to end up with an ELF object file.</P
|
|
><P
|
|
>You don't necessarily have to rebuild all your LKMs and your base
|
|
kernel image at the same time (e.g. you could build just the base
|
|
kernel and use LKMs you built earlier with it) but it is always a good
|
|
idea. See <A
|
|
HREF="#BASEKERNCOMPAT"
|
|
>Section 6</A
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><HR><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN146"
|
|
></A
|
|
>4. LKM Utilities</H1
|
|
><P
|
|
>The programs you need to load and unload and otherwise work with LKMs
|
|
are in the package <SPAN
|
|
CLASS="APPLICATION"
|
|
>modutils</SPAN
|
|
>. You can find
|
|
this package in
|
|
<A
|
|
HREF="http://www.kernel.org/pub/linux/utils/kernel/modutils"
|
|
TARGET="_top"
|
|
>this directory</A
|
|
>.</P
|
|
><P
|
|
>This package contains the following programs to help you use LKMs:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>insmod</DT
|
|
><DD
|
|
><P
|
|
>Insert an LKM into the kernel.</P
|
|
></DD
|
|
><DT
|
|
>rmmod</DT
|
|
><DD
|
|
><P
|
|
>Remove an LKM from the kernel.</P
|
|
></DD
|
|
><DT
|
|
>depmod</DT
|
|
><DD
|
|
><P
|
|
>Determine interdependencies between LKMs.</P
|
|
></DD
|
|
><DT
|
|
>kerneld</DT
|
|
><DD
|
|
><P
|
|
>Kerneld daemon program</P
|
|
></DD
|
|
><DT
|
|
>ksyms</DT
|
|
><DD
|
|
><P
|
|
>Display symbols that are exported by the kernel for
|
|
use by new LKMs.</P
|
|
></DD
|
|
><DT
|
|
>lsmod</DT
|
|
><DD
|
|
><P
|
|
>List currently loaded LKMs.</P
|
|
></DD
|
|
><DT
|
|
>modinfo</DT
|
|
><DD
|
|
><P
|
|
>Display contents of <TT
|
|
CLASS="LITERAL"
|
|
>.modinfo</TT
|
|
> section in an
|
|
LKM object file.</P
|
|
></DD
|
|
><DT
|
|
>modprobe</DT
|
|
><DD
|
|
><P
|
|
> Insert or remove an LKM or set
|
|
of LKMs intelligently. For example, if you must load A before
|
|
loading B, Modprobe will automatically load A when you tell it
|
|
to load B.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>Changes to the kernel often require changes to
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>modutils</SPAN
|
|
>, so be sure you're using a current
|
|
version of <SPAN
|
|
CLASS="APPLICATION"
|
|
>modutils</SPAN
|
|
> whenever you upgrade
|
|
your kernel. <SPAN
|
|
CLASS="APPLICATION"
|
|
>modutils</SPAN
|
|
> is always backward
|
|
compatible (it works with older kernels), so there's no such thing as
|
|
having too new a <SPAN
|
|
CLASS="APPLICATION"
|
|
>modutils</SPAN
|
|
>.</P
|
|
><P
|
|
>Warning: <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> invokes <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
>
|
|
and has its location hardcoded as <TT
|
|
CLASS="FILENAME"
|
|
>/sbin/insmod</TT
|
|
>.
|
|
There may be other instances in <SPAN
|
|
CLASS="APPLICATION"
|
|
>modutils</SPAN
|
|
> of
|
|
the PATH not being used to find programs. So either modify the source
|
|
code of <SPAN
|
|
CLASS="APPLICATION"
|
|
>modutils</SPAN
|
|
> before you build it, or
|
|
make sure you install the programs in their conventional directories.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><HR><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN197"
|
|
></A
|
|
>5. How To Insert And Remove LKMs</H1
|
|
><P
|
|
>The basic programs for inserting and removing LKMs are
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> and
|
|
<B
|
|
CLASS="COMMAND"
|
|
>rmmod</B
|
|
>. See their man pages for details.</P
|
|
><P
|
|
>Inserting an LKM is conceptually easy: Just type, as superuser, a
|
|
command like
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>insmod serial.o</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
(<TT
|
|
CLASS="FILENAME"
|
|
>serial.o</TT
|
|
> contains the device driver for serial
|
|
ports (UARTs)).</P
|
|
><P
|
|
>However, I would be misleading you if I said the command just works. It
|
|
is very common, and rather maddening, for the command to fail either with
|
|
a message about a module/kernel version mismatch or a pile of unresolved
|
|
symbols.</P
|
|
><P
|
|
>If it does work, though, the way to prove to yourself that you know what
|
|
you're doing is to look at <TT
|
|
CLASS="FILENAME"
|
|
>/proc/modules</TT
|
|
> as
|
|
described in <A
|
|
HREF="#PROCMODULES"
|
|
>Section 5.5</A
|
|
>.</P
|
|
><P
|
|
>Note that the examples in this section are from Linux 2.4. In Linux 2.6,
|
|
the technical aspects of loading LKMs are considerably different, and
|
|
the most visible manifestation of this is that the LKM file has a suffix
|
|
of ".ko" instead of ".o". From the user point of
|
|
view, it looks quite similar, though.</P
|
|
><P
|
|
>Now lets look at a more difficult insertion. If you try
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>insmod msdos.o</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
you will probably get a raft of error messages like:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> msdos.o: unresolved symbol fat_date_unix2dos
|
|
msdos.o: unresolved symbol fat_add_cluster1
|
|
msdos.o: unresolved symbol fat_put_super
|
|
...</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>This is because msdos.o contains external symbol references to the
|
|
symbols mentioned and there are no such symbols exported by the kernel.
|
|
To prove this, do a
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>cat /proc/ksyms</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
to list every symbol that is exported by the kernel (i.e. available
|
|
for binding to LKMs). You will see that 'fat_date_unix2dos' is
|
|
nowhere in the list.</P
|
|
><P
|
|
>(In Linux 2.6, there is no <TT
|
|
CLASS="FILENAME"
|
|
>/proc/ksyms</TT
|
|
>. Use
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/proc/kallsyms</TT
|
|
> instead; the format is like the
|
|
output of <B
|
|
CLASS="COMMAND"
|
|
>nm</B
|
|
>: look for symbols labelled "t").</P
|
|
><P
|
|
>How do you get it into the list? By loading another LKM, one which
|
|
defines those symbols and exports them. In this case, it is the LKM
|
|
in the file <TT
|
|
CLASS="FILENAME"
|
|
>fat.o</TT
|
|
>. So do
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> insmod fat.o</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
and then see that "fat_date_unix2dos" is in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/proc/ksyms</TT
|
|
>. Now redo the
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>insmod msdos.o</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
and it works. Look at
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/proc/modules</TT
|
|
> and see that both LKMs are loaded
|
|
and one depends on the other:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>msdos 5632 0 (unused)
|
|
fat 30400 0 [msdos]</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>How did I know <TT
|
|
CLASS="FILENAME"
|
|
>fat.o</TT
|
|
> was the module I was
|
|
missing? Just a little ingenuity. A more robust way to address this
|
|
problem is to use <B
|
|
CLASS="COMMAND"
|
|
>depmod</B
|
|
> and
|
|
<B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> instead of
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
>, as discussed below.</P
|
|
><P
|
|
>When your symbols look like "fat_date_unix2dos_R83fb36a1",
|
|
the problem may be more complex than just getting prerequisite LKMs
|
|
loaded. See <A
|
|
HREF="#BASEKERNCOMPAT"
|
|
>Section 6</A
|
|
>.</P
|
|
><P
|
|
>When the error message is "kernel/module version mismatch," see
|
|
<A
|
|
HREF="#BASEKERNCOMPAT"
|
|
>Section 6</A
|
|
>.</P
|
|
><P
|
|
>Often, you need to pass parameters to the LKM when you insert it. For
|
|
example, a device driver wants to know the address and IRQ of the
|
|
device it is supposed to drive. Or the network driver wants to know
|
|
how much diagnostic tracing you want it to do. Here is an example of
|
|
that:</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>insmod ne.o io=0x300 irq=11</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>Here, I am loading the device driver for my NE2000-like Ethernet adapter
|
|
and telling it to drive the Ethernet adapter at IO address 0x300, which
|
|
generates interrupts on IRQ 11.</P
|
|
><P
|
|
>There are no standard parameters for LKMs and very few conventions.
|
|
Each LKM author decides what parameters <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> will
|
|
take for his LKM. Hence, you will find them documented in the
|
|
documentation of the LKM. This HOWTO also compiles a lot of LKM
|
|
parameter information in <A
|
|
HREF="#INDIVIDUAL"
|
|
>Section 15</A
|
|
>. For general
|
|
information about LKM parameters, see <A
|
|
HREF="#PARM"
|
|
>Section 8</A
|
|
>.</P
|
|
><P
|
|
>To remove an LKM from the kernel, the command is like
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>rmmod ne</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There is a command <B
|
|
CLASS="COMMAND"
|
|
>lsmod</B
|
|
> to list the
|
|
currently loaded LKMs, but all it does is dump the contents of
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/proc/modules</TT
|
|
>, with column headings, so you may
|
|
just want to go to the horse's mouth and forget about
|
|
<B
|
|
CLASS="COMMAND"
|
|
>lsmod</B
|
|
>.</P
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN248"
|
|
></A
|
|
>5.1. Could Not Find Kernel Version...</H2
|
|
><P
|
|
>A common error is to try to insert an object file which is not an LKM.
|
|
For example, you configure your kernel to have the USB core module
|
|
bound into the base kernel instead of generated as an LKM. In that
|
|
case, you end up with a file <TT
|
|
CLASS="FILENAME"
|
|
>usbcore.o</TT
|
|
>, which looks
|
|
pretty much the same as the <TT
|
|
CLASS="FILENAME"
|
|
>usbcore.o</TT
|
|
> you would get if
|
|
you built it as an LKM. But you can't <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> that
|
|
file.</P
|
|
><P
|
|
>So do you get an error message telling you that you should have
|
|
configured the kernel to make USB core function an LKM? Of course not.
|
|
This is Unix, and explanatory error messages are seen as a sign of
|
|
weakness. The error message is
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>$ insmod usbcore.o
|
|
usbcore.o: couldn't find the kernel version this module was compiled for</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>What <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> is telling you is that it looked in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>usbcore.o</TT
|
|
> for a piece of information any legitimate
|
|
LKM would have -- the kernel version with which the LKM was intended
|
|
to be used -- and it didn't find it. We know now that the reason it
|
|
didn't find it is that the file isn't an LKM. See
|
|
<A
|
|
HREF="#MODINFO"
|
|
>Section 10.2</A
|
|
> for information on how you can see what
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> is seeing and confirm that the file is not
|
|
in fact an LKM.</P
|
|
><P
|
|
>If this is a module you created yourself with the intention of it
|
|
being an LKM, the next question you have is: Why isn't an LKM? The
|
|
most usual cause of this is that you did not include
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>linux/module.h</TT
|
|
> at the top of your source code
|
|
and/or did not define the <TT
|
|
CLASS="LITERAL"
|
|
>MODULE></TT
|
|
> macro.
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>MODULE</TT
|
|
> is intended to be set via the compile
|
|
command (<TT
|
|
CLASS="LITERAL"
|
|
>-DMODULE</TT
|
|
>) and determine whether the
|
|
compilation produces an LKM or an object file for binding into the
|
|
base kernel. If your module is like most modern modules and can be
|
|
built <EM
|
|
>only</EM
|
|
> as an LKM, then you should just define
|
|
it in your source code (<TT
|
|
CLASS="LITERAL"
|
|
>#define MODULE</TT
|
|
>) before you
|
|
include <TT
|
|
CLASS="FILENAME"
|
|
>include/module.h</TT
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN269"
|
|
></A
|
|
>5.2. What Happens When An LKM Loads</H2
|
|
><P
|
|
>So you've successfully loaded an LKM, and verified that via
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/proc/modules</TT
|
|
>. But how do you know it's working?
|
|
That's up to the LKM, and varies according to what kind of LKM it is,
|
|
but here are some of the more common actions of an LKM upon being loaded.</P
|
|
><P
|
|
>The first thing a device driver LKM does after loading (which is what
|
|
the module would do at boot time if it were bound into the base
|
|
kernel) is usually to search the system for a device it knows how to
|
|
drive. Just how it does this search varies from one driver to the
|
|
next, and can usually be controlled by module parameters. But in any
|
|
case, if the driver doesn't find any device it is capable of driving,
|
|
it causes the load to fail. Otherwise, the driver registers itself
|
|
as the driver for a particular major number and you can start using
|
|
the device it found via a device special file that specifies that
|
|
major number. It may also register itself as the handler for the
|
|
interrupt level that the device uses. It may also send setup commands
|
|
to the device, so you may see lights blink or something like that.</P
|
|
><P
|
|
>You can see that a device driver has registered itself in the file
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/proc/devices</TT
|
|
>. You can see that the device
|
|
driver is handling the device's interrupts in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/proc/interrupts</TT
|
|
>.</P
|
|
><P
|
|
>A nice device driver issues kernel messages telling what devices it
|
|
found and is prepared to drive. (Kernel messages in most systems end
|
|
up on the console and in the file
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/var/log/messages</TT
|
|
>. You can also display recent
|
|
ones with the <B
|
|
CLASS="COMMAND"
|
|
>dmesg</B
|
|
> program). Some drivers, however, are
|
|
silent. A nice device driver also gives you (in kernel messages) some
|
|
details of its search when it fails to find a device, but many just
|
|
fail the load without explanation, and what you get is a list of
|
|
guesses from <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> as to what the problem might
|
|
have been.</P
|
|
><P
|
|
>A network device (interface) driver works similarly, except that the
|
|
LKM registers a device name of its choosing
|
|
(e.g. <TT
|
|
CLASS="LITERAL"
|
|
>eth0</TT
|
|
>) rather than a major number. You can
|
|
see the currently registered network device names in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/proc/net/dev</TT
|
|
></P
|
|
><P
|
|
>A filesystem driver, upon loading, registers itself as the driver for
|
|
a filesystem type of a certain name. For example, the
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>msdos</TT
|
|
> driver registers itself as the driver for the
|
|
filesystem type named <TT
|
|
CLASS="LITERAL"
|
|
>msdos</TT
|
|
>. (LKM authors typically
|
|
name the LKM the same as the filesystem type it will drive).</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="INTELLIGENT"
|
|
></A
|
|
>5.3. Intelligent Loading Of LKMs - Modprobe</H2
|
|
><P
|
|
>Once you have module loading and unloading figured out using
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> and <B
|
|
CLASS="COMMAND"
|
|
>rmmod</B
|
|
>, you can let
|
|
the system do more of the work for you by using the higher level
|
|
program <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
>. See the
|
|
<B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> man page for details.</P
|
|
><P
|
|
>The main thing that <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> does is automatically
|
|
load the prerequisites of an LKM you request. It does this with the
|
|
help of a file that you create with <B
|
|
CLASS="COMMAND"
|
|
>depmod</B
|
|
> and keep
|
|
on your system.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe msdos</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>This performs an <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> of
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>msdos.o</TT
|
|
>, but before that does an
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> of <TT
|
|
CLASS="FILENAME"
|
|
>fat.o</TT
|
|
>, since you
|
|
have to have <TT
|
|
CLASS="FILENAME"
|
|
>fat.o</TT
|
|
> loaded before you can load
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>msdos.o</TT
|
|
>.</P
|
|
><P
|
|
>The other major thing <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> does for you is to
|
|
find the object module containing the LKM given just the name of the
|
|
LKM. For example, <B
|
|
CLASS="COMMAND"
|
|
>modprobe msdos</B
|
|
> might load
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/lib/2.4.2-2/fs/msdos.o</TT
|
|
>.
|
|
In fact, <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
>'s argument may be a totally
|
|
symbolic name that you have associated with some actual module. For
|
|
example, <B
|
|
CLASS="COMMAND"
|
|
>modprobe eth0</B
|
|
> loads the appropriate network
|
|
device driver to create and drive your <TT
|
|
CLASS="LITERAL"
|
|
>eth0</TT
|
|
> device,
|
|
assuming you set that up properly in <TT
|
|
CLASS="FILENAME"
|
|
>modules.conf</TT
|
|
>.
|
|
Check out the man pages
|
|
for <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> and the configuration file
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>modules.conf</TT
|
|
> (usually
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/etc/modules.conf</TT
|
|
>) for details on the search
|
|
rules <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> uses.</P
|
|
><P
|
|
><B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> is especially important because it
|
|
is by default the program that the kernel module loader uses to load
|
|
an LKM on demand. So if you use automatic module loading, you will
|
|
need to set up <TT
|
|
CLASS="FILENAME"
|
|
>modules.conf</TT
|
|
> properly or
|
|
things will not work. See <A
|
|
HREF="#AUTOLOAD"
|
|
>Section 5.4</A
|
|
>.</P
|
|
><P
|
|
><B
|
|
CLASS="COMMAND"
|
|
>depmod</B
|
|
> scans your LKM object files (typically all
|
|
the <TT
|
|
CLASS="FILENAME"
|
|
>.o</TT
|
|
> files in the appropriate <TT
|
|
CLASS="FILENAME"
|
|
>/lib/modules</TT
|
|
> subdirectory) and figures
|
|
out which LKMs prerequire (refer to symbols in) other LKMs. It
|
|
generates a dependency file (typically named
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>modules.dep</TT
|
|
>), which you normally keep in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/lib/modules</TT
|
|
> for use by
|
|
<B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
>.</P
|
|
><P
|
|
>You can use <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> to remove stacks of LKMs as
|
|
well.</P
|
|
><P
|
|
>Via the LKM configuration file (typically
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/etc/modules.conf</TT
|
|
>), you can fine tune the
|
|
dependencies and do other fancy things to control LKM selections. And
|
|
you can specify programs to run when you insert and remove LKMs, for
|
|
example to initialize a device driver.</P
|
|
><P
|
|
>If you are maintaining one system and memory is not in short supply,
|
|
it is probably easier to avoid <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> and the
|
|
various files and directories it needs, and just do raw
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
>s in a startup script.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AUTOLOAD"
|
|
></A
|
|
>5.4. Automatic LKM Loading and Unloading</H2
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN338"
|
|
></A
|
|
>5.4.1. Automatic Loading</H3
|
|
><P
|
|
>You can cause an LKM to be loaded automatically when the kernel first
|
|
needs it. You do this with either the kernel module loader, which is
|
|
part of the Linux kernel, or the
|
|
older version of it, a <TT
|
|
CLASS="LITERAL"
|
|
>kerneld</TT
|
|
> daemon.</P
|
|
><P
|
|
>As an example, let's say you run a program that executes an open
|
|
system call for a file in an MS-DOS filesystem. But you don't have a
|
|
filesystem driver for the MS-DOS filesystem either bound into your
|
|
base kernel or loaded as an LKM. So the kernel does not know how to
|
|
access the file you're opening on the disk.</P
|
|
><P
|
|
>The kernel recognizes that it has no filesystem driver for MS-DOS, but
|
|
that one of the two automatic module loading facilities are available
|
|
and uses it to cause the LKM to be loaded. The kernel then proceeds
|
|
with the open.</P
|
|
><P
|
|
>Automatic kernel module loading is really not worth the complexity in most
|
|
modern systems. It may make sense in a very small memory system, because
|
|
you can keep parts of the kernel in memory only when you need them. But
|
|
the amount of memory these modules uses is so cheap today that you will
|
|
normally be a lot better off just loading all the modules you might need
|
|
via startup scripts and leaving them loaded.</P
|
|
><P
|
|
>Red Hat Linux uses automatic module loading via the kernel module loader.</P
|
|
><P
|
|
>Both the kernel module loader and <TT
|
|
CLASS="LITERAL"
|
|
>kerneld</TT
|
|
> use
|
|
<B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
>, ergo <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
>, to insert
|
|
LKMs. See <A
|
|
HREF="#INTELLIGENT"
|
|
>Section 5.3</A
|
|
>.</P
|
|
><DIV
|
|
CLASS="SECT4"
|
|
><HR><H4
|
|
CLASS="SECT4"
|
|
><A
|
|
NAME="AEN351"
|
|
></A
|
|
>5.4.1.1. Kernel Module Loader</H4
|
|
><P
|
|
>There is some documentation of the kernel module loader in the file
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>Documentation/kmod.txt</TT
|
|
> in the Linux 2.4 source
|
|
tree. This section is more complete and accurate than that file. You
|
|
can also look at its source code in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>kernel/kmod.c</TT
|
|
>.</P
|
|
><P
|
|
>The kernel module loader is an optional part of the Linux kernel. You
|
|
get it if you select the CONFIG_KMOD feature when you configure the
|
|
kernel at build time.</P
|
|
><P
|
|
>When a kernel that has the kernel module loader needs an LKM, it
|
|
creates a user process (owned by the superuser, though) that executes
|
|
<B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> to load the LKM, then exits. By default,
|
|
it finds <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> as
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/sbin/modprobe</TT
|
|
>, but you can set up any program
|
|
you like as <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> by writing its file name to
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/proc/sys/kernel/modprobe</TT
|
|
>. For example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># echo "sbin/mymodprobe" >/proc/sys/kernel/modprobe</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>The kernel module loader passes the following arguments to the
|
|
<B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
>: Argument Zero is the full file name of
|
|
<B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
>. The regular arguments are
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>-s</TT
|
|
>, <TT
|
|
CLASS="LITERAL"
|
|
>-k</TT
|
|
>, and the name of the LKM
|
|
that the kernel wants. <TT
|
|
CLASS="LITERAL"
|
|
>-s</TT
|
|
> is the user-hostile
|
|
form of <TT
|
|
CLASS="LITERAL"
|
|
>--syslog</TT
|
|
>; <TT
|
|
CLASS="LITERAL"
|
|
>-k</TT
|
|
> is the
|
|
cryptic way to say <TT
|
|
CLASS="LITERAL"
|
|
>--autoclean</TT
|
|
>. I.e. messages
|
|
from <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> will go to syslog and the loaded
|
|
LKM will have the "autoclean" flag set.</P
|
|
><P
|
|
>The most important part of the <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> invocation
|
|
is, of course, the module name. Note that the "module name"
|
|
argument to <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> is not necessarily a real
|
|
module name. It is often a symbolic name representing the role that
|
|
module plays and you use an <TT
|
|
CLASS="LITERAL"
|
|
>alias</TT
|
|
> statement in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>modules.conf</TT
|
|
> to tell what LKM gets loaded.
|
|
For example, if your Ethernet adapter requires the <TT
|
|
CLASS="LITERAL"
|
|
>3c59x</TT
|
|
>
|
|
LKM, you would have probably need the line
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>alias eth0 3c59x</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
in <TT
|
|
CLASS="FILENAME"
|
|
>/etc/modules.conf</TT
|
|
>.
|
|
Here
|
|
is what the kernel module loader uses for a module name in some of the
|
|
more popular cases (there are about 20 cases in which the kernel calls
|
|
on the kernel module loader to load a module):
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>When you try access a device and no device driver has
|
|
registered to serve that device's major number, the kernel requests
|
|
the module by the name
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>block-major-</TT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>N</TT
|
|
> or
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>char-major-</TT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>N</TT
|
|
> where
|
|
<TT
|
|
CLASS="VARNAME"
|
|
>N</TT
|
|
> is the major number in decimal without leading
|
|
zeroes. </P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>When you try to access a network interface (maybe by running
|
|
<B
|
|
CLASS="COMMAND"
|
|
>ifconfig</B
|
|
> against it) and no network device driver
|
|
has registered to serve an interface by that name, the kernel requests
|
|
the module named the same as the interface name
|
|
(e.g. <TT
|
|
CLASS="LITERAL"
|
|
>eth0</TT
|
|
>). This applies to drivers for non-physical
|
|
interfaces such as <TT
|
|
CLASS="LITERAL"
|
|
>ppp0</TT
|
|
> as well.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>When you try to access a socket in a protocol family which no
|
|
protocol driver has registered to drive, the kernel requests the
|
|
module named <TT
|
|
CLASS="FILENAME"
|
|
>net-pf-</TT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>N</TT
|
|
>, where
|
|
<TT
|
|
CLASS="VARNAME"
|
|
>N</TT
|
|
> is the protocol family number (in decimal without
|
|
leading zeroes).</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>When you try to NFS export a directory or otherwise
|
|
access the NFS server via the NFS system call, the kernel requests the
|
|
module named <TT
|
|
CLASS="FILENAME"
|
|
>nfsd</TT
|
|
>. </P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>The ATA device driver (named <TT
|
|
CLASS="FILENAME"
|
|
>ide</TT
|
|
>)
|
|
loads the relevant drivers for classes of ATA devices by the names:
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>ide-disk</TT
|
|
>, <TT
|
|
CLASS="FILENAME"
|
|
>ide-cd</TT
|
|
>,
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>ide-floppy</TT
|
|
>, <TT
|
|
CLASS="FILENAME"
|
|
>ide-tape</TT
|
|
>, and
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>ide-scsi</TT
|
|
>. </P
|
|
></LI
|
|
></UL
|
|
> </P
|
|
><P
|
|
>The kernel module loader runs <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> with the
|
|
following environment variables (only): HOME=<TT
|
|
CLASS="LITERAL"
|
|
>/</TT
|
|
>;
|
|
TERM=<TT
|
|
CLASS="LITERAL"
|
|
>linux</TT
|
|
>;
|
|
PATH=<TT
|
|
CLASS="LITERAL"
|
|
>/sbin:/usr/sbin:/bin:/usr/bin</TT
|
|
>.</P
|
|
><P
|
|
>The kernel module loader was new in Linux 2.2 and was designed to take
|
|
the place of <TT
|
|
CLASS="LITERAL"
|
|
>kerneld</TT
|
|
>. It does not, however, have all
|
|
the features of <TT
|
|
CLASS="LITERAL"
|
|
>kerneld</TT
|
|
>.</P
|
|
><P
|
|
>In Linux 2.2, the kernel module loader creates the above mentioned
|
|
process directly. In Linux 2.4, the kernel module loader submits the
|
|
module loading work to Keventd and it runs as a child process of
|
|
Keventd.</P
|
|
><P
|
|
>The kernel module loader is a pretty strange beast. It violates
|
|
layering as Unix programmers generally understand it and consequently
|
|
is inflexible, hard to understand, and not robust. Many system
|
|
designers would bristle just at the fact that it has the PATH
|
|
hardcoded. You may prefer to use <TT
|
|
CLASS="LITERAL"
|
|
>kerneld</TT
|
|
> instead,
|
|
or not bother with automatic loading of LKMs at all.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT4"
|
|
><HR><H4
|
|
CLASS="SECT4"
|
|
><A
|
|
NAME="AEN422"
|
|
></A
|
|
>5.4.1.2. Kerneld</H4
|
|
><P
|
|
><TT
|
|
CLASS="LITERAL"
|
|
>kerneld</TT
|
|
> is explained at length in the Kerneld
|
|
mini-HOWTO, available from the <A
|
|
HREF="http://www.tldp.org"
|
|
TARGET="_top"
|
|
>Linux
|
|
Documentation Project</A
|
|
>.</P
|
|
><P
|
|
><TT
|
|
CLASS="LITERAL"
|
|
>kerneld</TT
|
|
> is a user process, which runs the
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>kerneld</SPAN
|
|
> program from the
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>modutils</SPAN
|
|
> package. <TT
|
|
CLASS="LITERAL"
|
|
>kerneld</TT
|
|
>
|
|
sets up an IPC message channel with the kernel. When the kernel needs
|
|
an LKM, it sends a message on that channel to <TT
|
|
CLASS="LITERAL"
|
|
>kerneld</TT
|
|
>
|
|
and <TT
|
|
CLASS="LITERAL"
|
|
>kerneld</TT
|
|
> runs <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
>
|
|
to load the LKM, then sends a message back to the kernel to say that it
|
|
is done.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN435"
|
|
></A
|
|
>5.4.2. Automatic Unloading - Autoclean</H3
|
|
><DIV
|
|
CLASS="SECT4"
|
|
><H4
|
|
CLASS="SECT4"
|
|
><A
|
|
NAME="AEN437"
|
|
></A
|
|
>5.4.2.1. The Autoclean Flag</H4
|
|
><P
|
|
>Each loaded LKM has an autoclean flag which can be set or unset.
|
|
You control this flag with parameters to the
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>init_module</TT
|
|
> system call. Assuming you do that via
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
>, you use the <TT
|
|
CLASS="LITERAL"
|
|
>--autoclean</TT
|
|
>
|
|
option.</P
|
|
><P
|
|
>You can see the state of the autoclean flag in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/proc/modules</TT
|
|
>. Any LKM that has the flag set has
|
|
the legend <TT
|
|
CLASS="LITERAL"
|
|
>autoclean</TT
|
|
> next to it.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT4"
|
|
><HR><H4
|
|
CLASS="SECT4"
|
|
><A
|
|
NAME="AEN446"
|
|
></A
|
|
>5.4.2.2. Removing The Autoclean LKMs</H4
|
|
><P
|
|
>The purpose of the autoclean flag is to let you automatically
|
|
remove LKMs that haven't been used in a while (typically 1 minute).
|
|
So by using automatic module loading and unloading, you can keep loaded only
|
|
parts of the kernel that are presently needed, and save memory.</P
|
|
><P
|
|
>This is less important than it once was, with memory being much
|
|
cheaper. If you don't need to save memory, you shouldn't bother with
|
|
the complexity of module loader processes. Just load everything you
|
|
might need via an initialization script and keep it loaded.</P
|
|
><P
|
|
>There is a form of the <TT
|
|
CLASS="LITERAL"
|
|
>delete_module</TT
|
|
> system call that
|
|
says, "remove all LKMs that have the autoclean flag set and haven't
|
|
been used in a while." Kerneld typically calls this once per
|
|
minute. You can call it explicitly with an <B
|
|
CLASS="COMMAND"
|
|
>rmmod --all</B
|
|
>
|
|
command.</P
|
|
><P
|
|
>As the kernel module loader does not do any removing of LKMs, if you
|
|
use that you might want to have a cron job that does a <B
|
|
CLASS="COMMAND"
|
|
>rmmod
|
|
--all</B
|
|
> periodically.</P
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="PROCMODULES"
|
|
></A
|
|
>5.5. /proc/modules</H2
|
|
><P
|
|
>To see the presently loaded LKMs, do
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>cat /proc/modules</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>You see a line like </P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>serial 24484 0</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>The left column is the name of the LKM, which is normally the name of
|
|
the object file from which you loaded it, minus the ".o" suffix.
|
|
You can, however, choose any name you like with an option on
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
>.</P
|
|
><P
|
|
>The "24484" is the size in bytes of the LKM in memory.</P
|
|
><P
|
|
>The "0" is the use count. It tells how many things presently depend
|
|
on the LKM being loaded. Typical "things" are open devices
|
|
or mounted fileystems. It is important because you cannot remove an
|
|
LKM unless the use count is zero. The LKM itself maintains this
|
|
count, but the module manager uses it to decide whether to permit an
|
|
unload.</P
|
|
><P
|
|
>There is an exception to the above description of the use count. You
|
|
may see -1 in the use count column. What that means is that this LKM
|
|
does not use use counts to determine when it is OK to unload.
|
|
Instead, the LKM has registered a subroutine that the module manager
|
|
can call that will return an indication of whether or not it is OK to
|
|
unload the LKM. In this case, the LKM ought to provide you with some
|
|
custom interface, and some documentation, to determine when the LKM is
|
|
free to be unloaded.</P
|
|
><P
|
|
>Do not confuse use count with "dependencies", which are
|
|
described below.</P
|
|
><P
|
|
>Here is another example, with more information:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>lp 5280 0 (unused)
|
|
parport_pc 7552 1
|
|
parport 7600 1 [lp parport_pc]</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
The stuff in square brackets ("[lp parport_pc]") describes
|
|
dependencies. Here, the modules <TT
|
|
CLASS="LITERAL"
|
|
>lp</TT
|
|
> and
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>parport_pc</TT
|
|
> both refer to addresses within module
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>parport</TT
|
|
> (via external symbols that
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>parport</TT
|
|
> exports). So <TT
|
|
CLASS="LITERAL"
|
|
>lp</TT
|
|
> and
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>parport_pc</TT
|
|
> are "dependent" on (and are
|
|
"dependencies of") <TT
|
|
CLASS="LITERAL"
|
|
>parport</TT
|
|
>.</P
|
|
><P
|
|
>You cannot unload an LKM that has dependencies. But you can remove those
|
|
dependencies by unloading the dependent LKMs.</P
|
|
><P
|
|
>The "(unused)" legend means the LKM has never been used,
|
|
i.e. it has never been in a state where it could not be unloaded. The
|
|
kernel tracks this information for one simple reason: to assist in
|
|
automatic LKM unloading policy. In a system where LKMs are loaded and
|
|
unloaded automatically (see <A
|
|
HREF="#AUTOLOAD"
|
|
>Section 5.4</A
|
|
>), you don't want
|
|
to automatically load an LKM and then, before the guy who needed it
|
|
loaded has a chance to use it, unload it because it is not in use.</P
|
|
><P
|
|
>Here is something you won't normally see:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>mydriver 8154 0 (deleted)</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
This is an LKM that is in "deleted" state. It's something of a
|
|
misnomer -- what it means is that the LKM is in the process of being
|
|
unloaded. You can no longer load LKMs that depend on it, but it's still
|
|
present in the system. Unloading an LKM is usually close to instantaneous,
|
|
so if you see this status, you probably have a broken LKM. Its cleanup
|
|
routine probably got into an infinite loop or stall or crashed (causing a
|
|
kernel oops). If that's the case, the only way to clear this status is to
|
|
reboot.</P
|
|
><P
|
|
>There are similar statuses "initializing" and
|
|
"uninitialized".</P
|
|
><P
|
|
>The legend "(autoclean)" refers to the autoclean flag,
|
|
discussed in <A
|
|
HREF="#AUTOLOAD"
|
|
>Section 5.4</A
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="MODLOCATION"
|
|
></A
|
|
>5.6. Where Are My LKM Files On My System?</H2
|
|
><P
|
|
>The LKM world is flexible enough that the files you need to load could
|
|
live just about anywhere on your system, but there is a convention
|
|
that most systems follow: The LKM .o files are in the directory
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/lib/modules</TT
|
|
>, divided
|
|
into subdirectories. There is one subdirectory for each version of
|
|
the kernel, since LKMs are specific to a kernel (see <A
|
|
HREF="#BASEKERNCOMPAT"
|
|
>Section 6</A
|
|
>). Each subdirectory contains a complete set
|
|
of LKMs.</P
|
|
><P
|
|
>The subdirectory name is the value you get from the <B
|
|
CLASS="COMMAND"
|
|
>uname
|
|
--release</B
|
|
> command, for example <TT
|
|
CLASS="LITERAL"
|
|
>2.2.19</TT
|
|
>.
|
|
<A
|
|
HREF="#MULTIPLEKERNELS"
|
|
>Section 6.3</A
|
|
> tells how you control that value.</P
|
|
><P
|
|
>When you build Linux, a standard <B
|
|
CLASS="COMMAND"
|
|
>make modules</B
|
|
> and
|
|
<B
|
|
CLASS="COMMAND"
|
|
>make modules_install</B
|
|
> should install all the LKMs
|
|
that are part of Linux in the proper release subdirectory.</P
|
|
><P
|
|
>If you build a lot of kernels, another organization may be more
|
|
helpful: keep the LKMs together with the base kernel and other kernel-related
|
|
files in a subdirectory of /boot. The only drawback of this is that you
|
|
cannot have /boot reside on a tiny disk partition. In some systems, /boot
|
|
is on a special tiny "boot partition" and contains only enough files
|
|
to get the system up to the point that it can mount other filesystems.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><HR><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="BASEKERNCOMPAT"
|
|
></A
|
|
>6. Unresolved Symbols</H1
|
|
><P
|
|
>The most common and most frustrating failure in loading an LKM is a bunch
|
|
of error messages about unresolved symbols, like this:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> msdos.o: unresolved symbol fat_date_unix2dos
|
|
msdos.o: unresolved symbol fat_add_cluster1
|
|
msdos.o: unresolved symbol fat_put_super
|
|
...</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
There are actually a bunch of different problems that result in this
|
|
symptom. In any case, you can get closer to the problem by looking at
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/proc/ksyms</TT
|
|
> and confirming that the symbols in the
|
|
message are indeed not in the list.</P
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN502"
|
|
></A
|
|
>6.1. Some LKMs Prerequire Other LKMs</H2
|
|
><P
|
|
>One reason you get this is because you have not loaded another
|
|
LKM that contains instructions or data that your LKM needs to access.
|
|
A primary purpose of <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> is to avoid this
|
|
failure. See <A
|
|
HREF="#INTELLIGENT"
|
|
>Section 5.3</A
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN507"
|
|
></A
|
|
>6.2. An LKM Must Match The Base Kernel</H2
|
|
><P
|
|
>The designers of loadable kernel modules realized there would be a
|
|
problem with having the kernel in multiple files, possibly distributed
|
|
independently of one another. What if the LKM
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>mydriver.o</TT
|
|
> was written and compiled to work with
|
|
the Linux 1.2.1 base kernel, and then someone tried to load it into a
|
|
Linux 1.2.2 kernel? What if there was a change between 1.2.1 and
|
|
1.2.2 in the way a kernel subroutine that
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>mydriver.o</TT
|
|
> calls works? These are internal
|
|
kernel subroutines, so what's to stop them from changing from one
|
|
release to the next? You could end up with a broken kernel.</P
|
|
><P
|
|
>To address this problem, the creators of LKMs endowed them with a
|
|
kernel version number. The special <TT
|
|
CLASS="LITERAL"
|
|
>.modinfo</TT
|
|
>
|
|
section of the <TT
|
|
CLASS="FILENAME"
|
|
>mydriver.o</TT
|
|
> object file in this example has
|
|
"1.2.1" in it because it was compiled using header files from Linux
|
|
1.2.1. Try to load it into a 1.2.2 kernel and
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> notices the mismatch and fails,
|
|
telling you you have a kernel version mismatch.</P
|
|
><P
|
|
>But wait. What's the chance that there really is an incompatibility
|
|
between Linux 1.2.1 and 1.2.2 that will affect
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>mydriver.o</TT
|
|
>? <TT
|
|
CLASS="FILENAME"
|
|
>mydriver.o</TT
|
|
> only
|
|
calls a few subroutines and accesses a few data structures. Surely
|
|
they don't change with every minor release. Must we recompile every
|
|
LKM against the header files for the particular kernel into which we
|
|
want to insert it?</P
|
|
><P
|
|
>To ease this burden, <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> has a
|
|
<TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>-f</I
|
|
></TT
|
|
> option that "forces"
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> to ignore the kernel version
|
|
mismatch and insert the module anyway. Because it is so unusual for
|
|
there to be a significant difference between any two kernel versions,
|
|
I recommend you always use <TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>-f</I
|
|
></TT
|
|
>. You will, however,
|
|
still get a warning message about the mismatch. There's no way to
|
|
shut that off.</P
|
|
><P
|
|
>But LKM designers still wanted to address the problem of incompatible
|
|
changes that do occasionally happen. So they invented a very clever
|
|
way to allow the LKM insertion process to be sensitive to the actual
|
|
content of each kernel subroutine the LKM uses. It's called symbol
|
|
versioning (or sometimes less clearly, "module versioning."). It's
|
|
optional, and you select it when you configure the kernel via the
|
|
"CONFIG_MODVERSIONS" kernel configuration option. </P
|
|
><P
|
|
>When you build a base kernel or LKM with symbol versioning, the
|
|
various symbols exported for use by LKMs get defined as macros. The
|
|
definition of the macro is the same symbol name plus a hexadecimal
|
|
hash value of the parameter and return value types for the subroutine
|
|
named by the symbol (based on an analysis by the program
|
|
<B
|
|
CLASS="COMMAND"
|
|
>genksyms</B
|
|
> of the source code for the subroutine).
|
|
So let's look at the <TT
|
|
CLASS="FUNCTION"
|
|
>register_chrdev</TT
|
|
> subroutine.
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>register_chrdev</TT
|
|
> is a subroutine in the base
|
|
kernel that device driver LKMs often call. With symbol versioning,
|
|
there is a C macro definition like</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
> #define register_chrdev register_chrdev_Rc8dc8350</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>This macro definition is in effect both in the C source file that
|
|
defines <TT
|
|
CLASS="FUNCTION"
|
|
>register_chrdev</TT
|
|
> and in any C source file
|
|
that refers to <TT
|
|
CLASS="FUNCTION"
|
|
>register_chrdev</TT
|
|
>, so while your
|
|
eyes see <TT
|
|
CLASS="FUNCTION"
|
|
>register_chrdev</TT
|
|
> as you read the code,
|
|
the C preprocessor knows that the function is really called
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>register_chrdev_Rc8dc8350</TT
|
|
>.</P
|
|
><P
|
|
>What is the meaning of that garbage suffix? It is a hash of the data
|
|
types of the parameters and return value of
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>register_chrdev</TT
|
|
>. No two combinations of
|
|
parameter and return value types have the same hash value.</P
|
|
><P
|
|
>So let's say someone adds a paramater to
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>register_chrdev</TT
|
|
> between Linux 1.2.1 and Linux
|
|
1.2.2. In 1.2.1, <TT
|
|
CLASS="LITERAL"
|
|
>register_chrdev</TT
|
|
> is a macro for
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>register_chrdev_Rc8dc8350</TT
|
|
>, but in 1.2.2, it is a
|
|
macro for <TT
|
|
CLASS="LITERAL"
|
|
>register_chrdev_R12f8dc01</TT
|
|
>. In
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>mydriver.o</TT
|
|
>, compiled with Linux 1.2.1 header
|
|
files, there is an external reference to
|
|
<TT
|
|
CLASS="VARNAME"
|
|
>register_chrdev_Rc8dc8350</TT
|
|
>, but there is no such
|
|
symbol exported by the 1.2.2 base kernel. Instead, the 1.2.2 base
|
|
kernel exports a symbol <TT
|
|
CLASS="VARNAME"
|
|
>register_chrdev_R12f8dc01</TT
|
|
>.</P
|
|
><P
|
|
>So if you try to insmod this 1.2.1 <TT
|
|
CLASS="FILENAME"
|
|
>mydriver.o</TT
|
|
>
|
|
into this 1.2.2 base kernel, you will fail. And the error message
|
|
isn't one about mismatched kernel versions, but simply "unresolved
|
|
symbol reference."</P
|
|
><P
|
|
>As clever as this is, it actually works against you sometimes. The
|
|
way <B
|
|
CLASS="COMMAND"
|
|
>genksyms</B
|
|
> works, it often generates different
|
|
hash values for parameter lists that are essentially the same.</P
|
|
><P
|
|
>And symbol versioning doesn't even guarantee compatibility. It
|
|
catches only a small subset of the kinds of changes in the definition
|
|
of a function that can make it not backward compatible. If the way
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>register_chrdev</TT
|
|
> interprets one of its parameters
|
|
changes in a non-backward-compatible way, its version suffix won't
|
|
change -- the parameter still has the same C type.</P
|
|
><P
|
|
>And there's no way an option like <TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>-f</I
|
|
></TT
|
|
> on
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> can get around this.</P
|
|
><P
|
|
>So it is generally not wise to use symbol versioning.</P
|
|
><P
|
|
>Of course, if you have a base kernel that was compiled with symbol
|
|
versioning, then you must have all your LKMs compiled likewise, and
|
|
vice versa. Otherwise, you're guaranteed to get those "unresolved
|
|
symbol reference" errors.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="MULTIPLEKERNELS"
|
|
></A
|
|
>6.3. If You Run Multiple Kernels</H2
|
|
><P
|
|
>Now that we've seen how you often have different versions of an LKM
|
|
for different base kernels, the question arises as to what to do
|
|
about a system that has multiple kernel versions (i.e. you can
|
|
choose a kernel at boot time). You want to make sure that the
|
|
LKMs built for Kernel A get inserted when you boot Kernel A, but
|
|
the LKMs built for Kernel B get inserted when you boot Kernel B.</P
|
|
><P
|
|
>In particular, whenever you upgrade your kernel, if you're smart,
|
|
you keep both the new kernel and the old kernel on the system
|
|
until you're sure the new one works.</P
|
|
><P
|
|
>The most common way to do this is with the LKM-hunting feature of
|
|
<B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
>. <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
>
|
|
understands the conventional LKM file organization described in
|
|
<A
|
|
HREF="#MODLOCATION"
|
|
>Section 5.6</A
|
|
> and loads LKMs from the appropriate
|
|
subdirectory depending on the kernel that is running.</P
|
|
><P
|
|
>You set the <B
|
|
CLASS="COMMAND"
|
|
>uname --release</B
|
|
> value, which is the
|
|
name of the subdirectory in which <B
|
|
CLASS="COMMAND"
|
|
>modprobe</B
|
|
> looks,
|
|
by editing the main kernel makefile when you build the kernel and
|
|
setting the VERSION, PATCHLEVEL, SUBLEVEL, and EXTRAVERSION variables
|
|
at the top.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN567"
|
|
></A
|
|
>6.4. SMP symbols</H2
|
|
><P
|
|
>Besides the checksum mentioned above, the symbol version prefix contains
|
|
"smp" if the symbol is defined in or referenced by code that was
|
|
built for symmetric multiprocessing (SMP) machines. That means it was
|
|
built for use on a system that may have more than one CPU. You choose
|
|
whether to build in SMP capability or not via the Linux kernel configuration
|
|
process (<B
|
|
CLASS="COMMAND"
|
|
>make config</B
|
|
>, etc.), to wit with the
|
|
CONFIG_SMP configuration option.</P
|
|
><P
|
|
>So if you use symbol versioning, you will get unresolved symbols if the
|
|
base kernel was built with SMP capability and the LKM you're inserting was
|
|
not, or vice versa.</P
|
|
><P
|
|
>If you don't use symbol versioning, never mind.</P
|
|
><P
|
|
>Note that there's generally no reason to omit SMP capability from a
|
|
kernel, even if you have only one CPU. Just because the capability is
|
|
there doesn't mean you have to have multiple CPUs. However, there are
|
|
some machines on which the SMP-capable kernel will not boot because it
|
|
reaches the conclusion that there are zero CPUs!</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN574"
|
|
></A
|
|
>6.5. You Are Not Licensed To Access The Symbol</H2
|
|
><P
|
|
>The copyright owners of some kernel code license their programs to the
|
|
public to make and use copies, but only in restricted ways. For
|
|
example, the license may say you may only call your copy of the
|
|
program from a program which is similarly licensed to the public.</P
|
|
><P
|
|
>(Is that confusing? Here's an example: Bob writes an LKM that provides
|
|
data compression subroutines to other LKMs. He licenses his program
|
|
to the public under the GNU Public License (GPL). According to some
|
|
interpretations, that license says if you make a copy of Bob's LKM,
|
|
you can't allow Mary's LKM to call its compression subroutines
|
|
if Mary does not supply her source code to the world too. The idea is to
|
|
encourage Mary to open up her source code).</P
|
|
><P
|
|
>To support and enforce such a license, the licensor can cause his
|
|
program to export symbols under a special name that is the real name
|
|
of the symbol plus the prefix "GPLONLY". A naive loader
|
|
of a client LKM would not be able to resolve those symbols. Example:
|
|
Bob's LKM provides the service bobsService() and declares it to be
|
|
a GPL symbol. The LKM consequently exports bobsService() under the
|
|
name GPLONLY_bobsService. If Mary's LKM refers to bobsService, the
|
|
naive loader will not be able to find it, so will fail to load Mary's
|
|
LKM.</P
|
|
><P
|
|
>However, a modern version of <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> knows to check
|
|
for GPLONLY_bobsService if it can't find bobsService. But the modern
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> will refuse to do so unless Mary's LKM
|
|
declares that it is licensed to the public under GPL.</P
|
|
><P
|
|
>The purpose of this appears to be to prevent anyone from accidentally
|
|
violating a license (or from credibly claiming that he accidentally
|
|
violated the license). It is not difficult to circumvent the
|
|
restriction if you want to.</P
|
|
><P
|
|
>If you see this failure, it is probably because you're using an old
|
|
loader (<B
|
|
CLASS="COMMAND"
|
|
>insmode</B
|
|
>) that doesn't know about GPLONLY.</P
|
|
><P
|
|
>The only other cause would be that the LKM author wrote the source
|
|
code in such a way that it will never load into any Linux kernel, so
|
|
there would be no point in the author distributing it.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN586"
|
|
></A
|
|
>6.6. An LKM Must Match Prerequisite LKMs</H2
|
|
><P
|
|
>The same ways an LKM must be compatible with the base kernel, it must
|
|
be compatible with any LKMs which it accesses (e.g. the first LKM calls a
|
|
subroutine in the second). The preceding sections limit their discussions
|
|
to the base kernel just to keep it simple.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><HR><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN589"
|
|
></A
|
|
>7. How To Boot Without A Disk Device Driver</H1
|
|
><P
|
|
>For most systems, the ATA disk device driver must be bound into the
|
|
base kernel because the root filesystem is on an ATA disk
|
|
<A
|
|
NAME="AEN592"
|
|
HREF="#FTN.AEN592"
|
|
><SPAN
|
|
CLASS="footnote"
|
|
>[2]</SPAN
|
|
></A
|
|
> and the kernel cannot mount the
|
|
root filesystem, much less read any LKMs from it, without the ATA disk
|
|
driver. But if you really want the device driver for your root
|
|
filesystem to be an LKM, here's how to do it with Initrd:</P
|
|
><P
|
|
>"Initrd" is the name of the "initial ramdisk" feature of Linux. With
|
|
this, you have your loader (probably LILO or Grub) load a filesystem into
|
|
memory (as a ramdisk) before starting the kernel. When it starts the
|
|
kernel, it tells it to mount the ramdisk as the root filesystem. You
|
|
put the disk device driver for your real root filesystem and all the
|
|
software you need to load it in that ramdisk filesystem. Your startup
|
|
programs (which live in the ramdisk) eventually mount the real (disk)
|
|
filesystem as the root filesystem. Note that a ramdisk doesn't
|
|
require any device driver.</P
|
|
><P
|
|
>This does not free you, however, from having to bind into the base
|
|
kernel 1) the filesystem driver for the filesystem in your ramdisk,
|
|
and 2) the executable interpreter for the programs in the ramdisk.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><HR><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="PARM"
|
|
></A
|
|
>8. About Module Parameters</H1
|
|
><P
|
|
>It is useful to compare parameters that get passed to LKMs and parameters
|
|
that get passed to modules that are bound into the base kernel, especially
|
|
since modules often can be run either way.</P
|
|
><P
|
|
>We've seen above that you pass parameters to an LKM by specifying
|
|
something like <TT
|
|
CLASS="LITERAL"
|
|
>io=0x300</TT
|
|
> on the
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> command. For a module that is bound into
|
|
the base kernel, you pass parameters to it via the kernel boot
|
|
parameters. One common way to specify kernel boot parameters is at a
|
|
<B
|
|
CLASS="COMMAND"
|
|
>lilo</B
|
|
> boot prompt. Another is with an
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>append</TT
|
|
> statement in the <B
|
|
CLASS="COMMAND"
|
|
>lilo</B
|
|
>
|
|
configuration file.</P
|
|
><P
|
|
>The kernel initializes an LKM at the time you load it. It initializes
|
|
a bound-in module at boot time.</P
|
|
><P
|
|
>Since there is only one string of kernel boot parameters, you need
|
|
some way within that string to identify which parameters go to which
|
|
modules. The rule for this is that if there is a module named
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>xyz</TT
|
|
>, then a kernel boot parameter named
|
|
<TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>xyz</I
|
|
></TT
|
|
> is for that module. The value of a kernel
|
|
boot parameter is an arbitrary string that makes sense only to the
|
|
module.</P
|
|
><P
|
|
>This is why you sometimes see an LKM whose only parameter is its own
|
|
name. E.g. you load the Mitsumi CDROM driver with a command like
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> insmod mcd mcd=0x340</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
It seems ridiculous to have the parameter named
|
|
<TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>mcd</I
|
|
></TT
|
|
> instead of, say, <TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>io</I
|
|
></TT
|
|
>,
|
|
but this is done for consistency with the case where you bind
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>mcd</TT
|
|
> into the base kernel, in which case you would
|
|
select the I/O port address with the characters
|
|
<TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>mcd=0x340</I
|
|
></TT
|
|
> in the kernel boot parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><HR><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN615"
|
|
></A
|
|
>9. Persistent Data</H1
|
|
><P
|
|
>Some LKMs are set up to retain information from one load to the next.
|
|
This is called persistent data. When you remove one of these LKMs
|
|
with <B
|
|
CLASS="COMMAND"
|
|
>rmmod</B
|
|
>, <B
|
|
CLASS="COMMAND"
|
|
>rmmod</B
|
|
> extracts
|
|
certain values from the LKM's working storage and stores them in a
|
|
file. When you next insert the LKM with <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
>,
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> reads the persistent data from the file and
|
|
inserts it into the LKM.</P
|
|
><P
|
|
>See the <TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>--persist</I
|
|
></TT
|
|
> option on
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> and <B
|
|
CLASS="COMMAND"
|
|
>rmmod</B
|
|
>.</P
|
|
><P
|
|
>Persistent data was introduced in November 2000.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><HR><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN627"
|
|
></A
|
|
>10. Technical Details</H1
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="HOWTHEYWORK"
|
|
></A
|
|
>10.1. How They Work</H2
|
|
><P
|
|
><B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> makes an <TT
|
|
CLASS="FUNCTION"
|
|
>init_module</TT
|
|
>
|
|
system call to load the LKM into kernel memory. Loading it is the
|
|
easy part, though. How does the kernel know to use it? The answer is
|
|
that the <TT
|
|
CLASS="FUNCTION"
|
|
>init_module</TT
|
|
> system call invokes the
|
|
LKM's initialization routine right after it loads the LKM.
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> passes to <TT
|
|
CLASS="FUNCTION"
|
|
>init_module</TT
|
|
>
|
|
the address of the subroutine in the LKM named
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>init_module</TT
|
|
> as its initialization routine.</P
|
|
><P
|
|
>(This is confusing -- every LKM has a subroutine named
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>init_module</TT
|
|
>, and the base kernel has a system
|
|
call by that same name, which is accessible via a subroutine in the
|
|
standard C library also named <TT
|
|
CLASS="FUNCTION"
|
|
>init_module</TT
|
|
>).</P
|
|
><P
|
|
>The LKM author set up <TT
|
|
CLASS="FUNCTION"
|
|
>init_module</TT
|
|
> to call a
|
|
kernel function that registers the subroutines that the LKM contains.
|
|
For example, a character device driver's
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>init_module</TT
|
|
> subroutine might call the kernel's
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>register_chrdev</TT
|
|
> subroutine, passing the major and
|
|
minor number of the device it intends to drive and the address of its
|
|
own "open" routine among the arguments.
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>register_chrdev</TT
|
|
> records in base kernel tables
|
|
that when the kernel wants to open that particular device, it should
|
|
call the open routine in our LKM.</P
|
|
><P
|
|
>But the astute reader will now ask how the LKM's
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>init_module</TT
|
|
> subroutine knew the address of the
|
|
base kernel's <TT
|
|
CLASS="FUNCTION"
|
|
>register_chrdev</TT
|
|
> subroutine. This
|
|
is not a system call, but an ordinary subroutine bound into the base
|
|
kernel. Calling it means branching to its address. So how does our
|
|
LKM, which was not compiled anywhere near the base kernel, know that
|
|
address? The answer to this is the relocation that happens at
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> time.</P
|
|
><P
|
|
>How that relocation happens is fundamentally different between Linux
|
|
2.4 and Linux 2.6. In 2.6, <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> pretty much just
|
|
passes the verbatim contents of the LKM file (.ko file) to the kernel
|
|
and the kernel does the relocation. In 2.4, <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> does
|
|
the relocation and passes a fully linked module image, ready to stuff
|
|
into kernel memory, to the kernel. <EM
|
|
>The description below
|
|
covers the 2.4 case.</EM
|
|
></P
|
|
><P
|
|
><B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> functions as a relocating linker/loader.
|
|
The LKM object file contains an external reference to the symbol
|
|
<TT
|
|
CLASS="VARNAME"
|
|
>register_chrdev</TT
|
|
>. <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> does a
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>query_module</TT
|
|
> system call to find out the
|
|
addresses of various symbols that the existing kernel exports.
|
|
<TT
|
|
CLASS="VARNAME"
|
|
>register_chrdev</TT
|
|
> is among these.
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>query_module</TT
|
|
> returns the address for which
|
|
<TT
|
|
CLASS="VARNAME"
|
|
>register_chrdev</TT
|
|
> stands and
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> patches that into the LKM where the LKM
|
|
refers to <TT
|
|
CLASS="VARNAME"
|
|
>register_chrdev</TT
|
|
>.</P
|
|
><P
|
|
>If you want to see the kind of information <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
>
|
|
can get from a <TT
|
|
CLASS="FUNCTION"
|
|
>query_module</TT
|
|
> system call, look at
|
|
the contents of <TT
|
|
CLASS="FILENAME"
|
|
>/proc/ksyms</TT
|
|
>.</P
|
|
><P
|
|
>Note that some LKMs call subroutines in other LKMs. They can do this
|
|
because of the <TT
|
|
CLASS="LITERAL"
|
|
>__ksymtab</TT
|
|
> and
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>.kstrtab</TT
|
|
> sections in the LKM object files. These
|
|
sections together list the external symbols within the LKM object file
|
|
that are supposed to be accessible by other LKMs inserted in the
|
|
future. <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> looks at
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>__ksymtab</TT
|
|
> and <TT
|
|
CLASS="LITERAL"
|
|
>.kstrtab</TT
|
|
> and tells
|
|
the kernel to add those symbols to its exported kernel symbols table.</P
|
|
><P
|
|
>To see this for yourself, insert the LKM <TT
|
|
CLASS="FILENAME"
|
|
>msdos.o</TT
|
|
>
|
|
and then notice in <TT
|
|
CLASS="FILENAME"
|
|
>/proc/ksyms</TT
|
|
> the symbol
|
|
<TT
|
|
CLASS="VARNAME"
|
|
>fat_add_cluster</TT
|
|
> (which is the name of a subroutine
|
|
in the <TT
|
|
CLASS="FILENAME"
|
|
>fat.o</TT
|
|
> LKM). Any subsequently inserted LKM
|
|
can branch to <TT
|
|
CLASS="VARNAME"
|
|
>fat_add_cluster</TT
|
|
>, and in fact
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>msdos.o</TT
|
|
> does just that.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="MODINFO"
|
|
></A
|
|
>10.2. The .modinfo Section</H2
|
|
><P
|
|
>An ELF object file consists of various named sections. Some of them
|
|
are basic parts of an object file, for example the
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>.text</TT
|
|
> section contains executable code that a
|
|
loader loads. But you can make up any section you want and have it
|
|
used by special programs. For the purposes of Linux LKMs, there is
|
|
the <TT
|
|
CLASS="LITERAL"
|
|
>.modinfo</TT
|
|
> section. An LKM doesn't have to have
|
|
a section named <TT
|
|
CLASS="LITERAL"
|
|
>.modinfo</TT
|
|
> to work, but the macros
|
|
you're supposed to use to code an LKM cause one to be generated, so
|
|
they generally do.</P
|
|
><P
|
|
>To see the sections of an object file, including the
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>.modinfo</TT
|
|
> section if it exists, use the
|
|
<B
|
|
CLASS="COMMAND"
|
|
>objdump</B
|
|
> program. For example:</P
|
|
><P
|
|
>To see all the sections in the object file for the msdos LKM:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>objdump msdos.o --section-headers</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
To see the contents of the <TT
|
|
CLASS="LITERAL"
|
|
>.modinfo</TT
|
|
> section:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>objdump msdos.o --full-contents --section=.modinfo</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>You can use the <B
|
|
CLASS="COMMAND"
|
|
>modinfo</B
|
|
> program to interpret the
|
|
contents of the <TT
|
|
CLASS="LITERAL"
|
|
>.modinfo</TT
|
|
> section.</P
|
|
><P
|
|
>So what is in the <TT
|
|
CLASS="LITERAL"
|
|
>.modinfo</TT
|
|
> section and who uses it?
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> uses the <TT
|
|
CLASS="LITERAL"
|
|
>.modinfo</TT
|
|
> section
|
|
for the following:
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>It contains the kernel release number for which the module was built.
|
|
I.e. of the kernel source tree whose header files were used in
|
|
compiling the module.</P
|
|
><P
|
|
><B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> uses that information as explained in
|
|
<A
|
|
HREF="#BASEKERNCOMPAT"
|
|
>Section 6</A
|
|
>.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>It describes the form of the LKM's parameters.
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> uses this information to format the
|
|
parameters you supply on the <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> command line
|
|
into data structure initial values, which <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
>
|
|
inserts into the LKM as it loads it.</P
|
|
></LI
|
|
></UL
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN712"
|
|
></A
|
|
>10.3. The __ksymtab And .kstrtab Sections</H2
|
|
><P
|
|
>Two other sections you often find in an LKM object file are named
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>__ksymtab</TT
|
|
> and <TT
|
|
CLASS="LITERAL"
|
|
>.kstrtab</TT
|
|
>.
|
|
Together, they list symbols in the LKM that should be accessible
|
|
(exported) to other parts of the kernel. A symbol is just a text name
|
|
for an address in the LKM. LKM A's object file can refer to an
|
|
address in LKM B by name (say, <TT
|
|
CLASS="LITERAL"
|
|
>getBinfo</TT
|
|
>"). When
|
|
you insert LKM A, after having inserted LKM B,
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> can insert into LKM A the actual address
|
|
within LKM B where the data/subroutine named
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>getBinfo</TT
|
|
> is loaded.</P
|
|
><P
|
|
>See <A
|
|
HREF="#HOWTHEYWORK"
|
|
>Section 10.1</A
|
|
> for more mind-numbing details of symbol binding.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN722"
|
|
></A
|
|
>10.4. Ksymoops Symbols</H2
|
|
><P
|
|
><B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> adds a bunch of exported symbols to the LKM
|
|
as it loads it. These symbols are all intended to help
|
|
<B
|
|
CLASS="COMMAND"
|
|
>ksymoops</B
|
|
> do its job. <B
|
|
CLASS="COMMAND"
|
|
>ksymoops</B
|
|
>
|
|
is a program that interprets and "oops" display. And
|
|
"oops" display is stuff that the Linux kernel displays when
|
|
it detects an internal kernel error (and consequently terminates a
|
|
process). This information contains a bunch of addresses in the
|
|
kernel, in hexadecimal.</P
|
|
><P
|
|
><B
|
|
CLASS="COMMAND"
|
|
>ksymoops</B
|
|
> looks at the hexadecimal addresses, looks
|
|
them up in the kernel symbol table (which you see in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/proc/ksyms</TT
|
|
> (Linux 2.4) or
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/proc/kallsyms</TT
|
|
> (Linux 2.6), and translates the
|
|
addresses in the oops message to symbolic addresses, which you might
|
|
be able to look up in an assembler listing.</P
|
|
><P
|
|
>So lets say you have an LKM crash on you. The oops message contains
|
|
the address of the instruction that choked, and what you want
|
|
<B
|
|
CLASS="COMMAND"
|
|
>ksymoops</B
|
|
> to tell you is 1) in what LKM is that
|
|
instruction, and 2) where is the instruction relative to an assembler
|
|
listing of that LKM? Similar questions arise for the data addresses
|
|
in the oops message.</P
|
|
><P
|
|
>To answer those questions, <B
|
|
CLASS="COMMAND"
|
|
>ksymoops</B
|
|
> must be able to
|
|
get the loadpoints and lengths of the various sections of the LKM from
|
|
the kernel symbol table.</P
|
|
><P
|
|
>Well, in Linux 2.4, <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> knows those addresses,
|
|
so it just creates symbols for them and includes them in the symbols
|
|
it loads with the LKM.</P
|
|
><P
|
|
>In particular, those symbols are named (and you can see this for
|
|
yourself by looking at <TT
|
|
CLASS="FILENAME"
|
|
>/proc/ksyms</TT
|
|
>):</P
|
|
><P
|
|
><TT
|
|
CLASS="LITERAL"
|
|
>__insmod_</TT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>name</TT
|
|
><TT
|
|
CLASS="LITERAL"
|
|
>_S</TT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>sectionname</TT
|
|
><TT
|
|
CLASS="LITERAL"
|
|
>_L</TT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>length</TT
|
|
></P
|
|
><P
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>name</TT
|
|
> is the LKM name (as you would see in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/proc/modules</TT
|
|
>.</P
|
|
><P
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>sectionname</TT
|
|
> is the section name, e.g. <TT
|
|
CLASS="LITERAL"
|
|
>.text</TT
|
|
>
|
|
(don't forget the leading period).</P
|
|
><P
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>length</TT
|
|
> is the length of the section, in decimal.</P
|
|
><P
|
|
>The value of the symbol is, of course, the address of the section.</P
|
|
><P
|
|
>Insmod also adds a pretty useful symbol that tells from what file
|
|
the LKM was loaded. That symbol's name is</P
|
|
><P
|
|
><TT
|
|
CLASS="LITERAL"
|
|
>__insmod_</TT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>name</TT
|
|
><TT
|
|
CLASS="LITERAL"
|
|
>_O</TT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>filespec</TT
|
|
><TT
|
|
CLASS="LITERAL"
|
|
>_M</TT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>mtime</TT
|
|
><TT
|
|
CLASS="LITERAL"
|
|
>_V<TT
|
|
CLASS="VARNAME"
|
|
>version</TT
|
|
></TT
|
|
></P
|
|
><P
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>name</TT
|
|
> is the LKM name, as above.</P
|
|
><P
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>filespec</TT
|
|
> is the file specification that was used to
|
|
identify the file containing the LKM when it was loaded. Note that it
|
|
isn't necessarily still under that name, and there are multiple
|
|
file specifications that might have been used to refer to the same
|
|
file. For example, <TT
|
|
CLASS="FILENAME"
|
|
>../dir1/mylkm.o</TT
|
|
> and
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/lib/dir1/mylkm.o</TT
|
|
>.</P
|
|
><P
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>mtime</TT
|
|
> is the modification time of that file, in
|
|
the standard Unix representation (seconds since 1969), in hexadecimal.</P
|
|
><P
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>version</TT
|
|
> tells the kernel version level for which
|
|
the LKM was built (same as in the <TT
|
|
CLASS="LITERAL"
|
|
>.modinfo</TT
|
|
> section).
|
|
It is the value of the macro <TT
|
|
CLASS="LITERAL"
|
|
>LINUX_VERSION_CODE</TT
|
|
>
|
|
in Linux's <TT
|
|
CLASS="FILENAME"
|
|
>linux/version.h</TT
|
|
> file. For example,
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>132101</TT
|
|
>.</P
|
|
><P
|
|
>The value of this symbol is meaningless.</P
|
|
><P
|
|
>In Linux 2.6, it works differently. (I haven't figured out how yet).</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN782"
|
|
></A
|
|
>10.5. Other Symbols</H2
|
|
><P
|
|
><B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
>
|
|
adds another symbol, similar to the <B
|
|
CLASS="COMMAND"
|
|
>ksymoops</B
|
|
>
|
|
symbols. This one tells where the persistent data lives in the
|
|
LKM, which <B
|
|
CLASS="COMMAND"
|
|
>rmmod</B
|
|
> needs to know in order to save
|
|
the persistent data.</P
|
|
><P
|
|
><TT
|
|
CLASS="LITERAL"
|
|
>__insmod_</TT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>name</TT
|
|
><TT
|
|
CLASS="LITERAL"
|
|
>_P</TT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>length</TT
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN793"
|
|
></A
|
|
>10.6. Debugging Symbols</H2
|
|
><P
|
|
>There is another kind of symbol that relates to an LKM: kallsyms
|
|
symbols. These are not exported symbols; they do not show up in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>proc/ksyms</TT
|
|
>. They refer to addresses in the
|
|
kernel that are nobody's business except the module they are in, and
|
|
are not meant to be referenced by anything except a debugger. Kdb,
|
|
the kernel debugger that comes with the Linux kernel, is one user of
|
|
kallsyms symbols.</P
|
|
><P
|
|
>The kallsyms facility works for both the base kernel and LKMs. For the
|
|
base kernel, you select it when you build the base kernel, with the
|
|
CONFIG_KALLSYMS configuration option. When you do that, the kernel
|
|
contains a kallsyms symbol for all the symbols in the base kernel
|
|
object files. You know your base kernel is participating in the kallsyms
|
|
facility if you see the symbol <TT
|
|
CLASS="LITERAL"
|
|
>__start___kallsyms</TT
|
|
>
|
|
in <TT
|
|
CLASS="FILENAME"
|
|
>/proc/ksyms</TT
|
|
>.</P
|
|
><P
|
|
>For an LKM, you decide at load time whether it will contain kallsyms
|
|
symbols. You include the kallsyms definitions in the data you pass to
|
|
the <TT
|
|
CLASS="LITERAL"
|
|
>init_module</TT
|
|
> system call to load the LKM.
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> does this if either 1) you specify the
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>--kallsyms</TT
|
|
> option, or 2) <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
>
|
|
determines, by looking at <TT
|
|
CLASS="FILENAME"
|
|
>/proc/ksyms</TT
|
|
>, that the
|
|
base kernel is participating in the kallsyms facility. The kallsyms that
|
|
<B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> defines are all the symbols in the LKM
|
|
object file. To wit, those are the symbols you see when you run
|
|
<B
|
|
CLASS="COMMAND"
|
|
>nm</B
|
|
> on the LKM object file.</P
|
|
><P
|
|
>Each loaded LKM that is participating in kallsyms has its own kallsyms
|
|
symbol table. When the base kernel is participating in the kallsyms
|
|
facility, the individual LKM kallysms symbol tables are linked into a
|
|
master symbol table so that a debugger can look up a symbol anywhere
|
|
in the kernel. When the base kernel is not participating in kallsyms,
|
|
a debugger must look explicitly at a particular LKM to find symbols
|
|
for that LKM. Kdb, for one, cannot do this. So the basic rule is: If
|
|
you're going to do any kernel debugging, use CONFIG_KALLSYMS.</P
|
|
><P
|
|
>Note that the <TT
|
|
CLASS="LITERAL"
|
|
>__kallsyms</TT
|
|
> section has nothing to do
|
|
with LKMs. That's a section in the base kernel object module. The
|
|
base kernel doesn't have the luxury of something as high-level as
|
|
sophisticated as <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> to load it, so it needs
|
|
that extra object file section to facilitate its participation in
|
|
kallsyms.</P
|
|
><P
|
|
>Similarly, the program <B
|
|
CLASS="COMMAND"
|
|
>kallsyms</B
|
|
> has nothing to do with
|
|
LKMs. It is what creates the <TT
|
|
CLASS="LITERAL"
|
|
>__kallsyms</TT
|
|
> section.</P
|
|
><P
|
|
>There is another kind of debugging symbol -- the kind that
|
|
<B
|
|
CLASS="COMMAND"
|
|
>gcc</B
|
|
> creates with its <TT
|
|
CLASS="LITERAL"
|
|
>-g</TT
|
|
> option.
|
|
These are unrelated to the kallsyms facility. They do not get loaded
|
|
into kernel memory. Kdb does not use them. But Kgdb (which gets
|
|
information both from kernel memory and source and object files) does.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="MEMALLOC"
|
|
></A
|
|
>10.7. Memory Allocation For Loading</H2
|
|
><P
|
|
>This section is about how Linux allocates memory in which to load an LKM.
|
|
It is not about how an LKM dynamically allocates memory, which is the same
|
|
as for any other part of the kernel.</P
|
|
><P
|
|
>The memory where an LKM resides is a little different from that where
|
|
the base kernel resides. The base kernel is always loaded into one
|
|
big contiguous area of real memory, whose real addresses are equal to
|
|
its virtual addresses. That's possible because the base kernel is the
|
|
first thing ever to get loaded (besides the loader) -- it has a wide
|
|
open empty space in which to load. And since the Linux kernel is not
|
|
pageable, it stays in its homestead forever.</P
|
|
><P
|
|
>By the time you load an LKM, real memory is all fragmented -- you
|
|
can't simply add the LKM to the end of the base kernel. But the LKM
|
|
needs to be in contiguous virtual memory, so Linux uses
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>vmalloc</TT
|
|
> to allocate a contiguous area of virtual
|
|
memory (in the kernel address space), which is probably not contiguous
|
|
in real memory. But <EM
|
|
>the memory is still not
|
|
pageable</EM
|
|
>. The LKM gets loaded into real page frames from
|
|
the start, and stays in those real page frames until it gets unloaded.</P
|
|
><P
|
|
>This design is based on the principle that it's much easier to get a
|
|
large contiguous area of virtual memory than to get a large contiguous
|
|
area of real memory because there is orders of magnitude more virtual
|
|
address space than real memory. In the early days of virtual memory,
|
|
that was certainly true -- a 32 bit machine had a 4GiB virtual address
|
|
space and rarely more than 64 MiB of real memory. Now, however, it's
|
|
quite often just the reverse, with virtual address space being the
|
|
constrained resource. So this LKM loading strategy may not make sense
|
|
on your system.</P
|
|
><P
|
|
>Some CPUs can take advantage of the properties of the base kernel to
|
|
effect faster access to base kernel memory. For example, on one
|
|
machine, the entire base kernel is covered by one page table entry
|
|
and consequently one entry in the translation lookaside buffer (TLB).
|
|
Naturally, that TLB entry is virtually always present. For LKMs on
|
|
this machine, there is a page table entry for each memory page into
|
|
which the LKM is loaded. Much more often, the entry for a page is not
|
|
in the TLB when the CPU goes to access it, which means a slower access.</P
|
|
><P
|
|
>This effect is probably trivial.</P
|
|
><P
|
|
>It is also said that PowerPC Linux does something with its address
|
|
translation so that transferring between accessing base kernel memory
|
|
to accessing LKM memory is costly. I don't know anything solid about
|
|
that.</P
|
|
><P
|
|
>The base kernel contains within its prized contiguous domain a large
|
|
expanse of reusable memory -- the kmalloc pool. In some versions of
|
|
Linux, the module loader tries first to get contiguous memory from
|
|
that pool into which to load an LKM and only if a large enough space
|
|
was not available, go to the vmalloc space. Andi Kleen submitted code
|
|
to do that in Linux 2.5 in October 2002. He claims the difference is
|
|
in the several per cent range.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN830"
|
|
></A
|
|
>10.8. Linux internals</H2
|
|
><P
|
|
>If you're interested in the internal workings of the Linux kernel with
|
|
respect to LKMs, this section can get you started. You should not need
|
|
to know any of this in order to develop, build, and use LKMs.</P
|
|
><P
|
|
>The code to handle LKMs is in the source files
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>kernel/module.c</TT
|
|
> in the Linux source tree.</P
|
|
><P
|
|
>The kernel module loader (see <A
|
|
HREF="#AUTOLOAD"
|
|
>Section 5.4</A
|
|
>) lives in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>kernel/kmod.c</TT
|
|
>.</P
|
|
><P
|
|
>(Ok, that wasn't much of a start, but at least I have a framework here
|
|
for adding this information in the future).</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><HR><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN839"
|
|
></A
|
|
>11. Writing Your Own Loadable Kernel Module</H1
|
|
><P
|
|
><A
|
|
HREF="http://tldp.org/LDP/lkmpg"
|
|
TARGET="_top"
|
|
><I
|
|
CLASS="CITETITLE"
|
|
>The Linux Kernel
|
|
Module Programming Guide</I
|
|
></A
|
|
> by Peter J Salzman,
|
|
Michael Burian, and Ori Pomerantz is a complete explanation of writing
|
|
your own LKM. This book is also available in print. There are two
|
|
versions of it: one for Linux 2.4, and another for 2.6.</P
|
|
><P
|
|
>At one time, the Linux 2.4 version of this document was rather out of
|
|
date and contained an error or two.</P
|
|
><P
|
|
>Here are a few things about writing an LKM that, at least at one time,
|
|
weren't in there. Let the author of the LKM HOWTO know if it's still
|
|
true. If not, he can remove this section from the LKM HOWTO.</P
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN846"
|
|
></A
|
|
>11.1. Simpler hello.c</H2
|
|
><P
|
|
>Lkmpg gives an example of the world's simplest LKM, hello-1.c. But it
|
|
is not as simple as it could be and depends on your having kernel
|
|
messaging set up a certain way on your system to see it work.
|
|
Finally, the program requires you to include <TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>-D</I
|
|
></TT
|
|
>
|
|
options on your compile command to work, because it does not define
|
|
some macros in the source code, where the definitions belong.</P
|
|
><P
|
|
>Here is an improved world's simplest LKM, <TT
|
|
CLASS="LITERAL"
|
|
>hello.c</TT
|
|
>.
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>/* hello.c
|
|
*
|
|
* "Hello, world" - the loadable kernel module version.
|
|
*
|
|
* Compile this with
|
|
*
|
|
* gcc -c hello.c -Wall
|
|
*/
|
|
|
|
/* Declare what kind of code we want from the header files */
|
|
#define __KERNEL__ /* We're part of the kernel */
|
|
#define MODULE /* Not a permanent part, though. */
|
|
|
|
/* Standard headers for LKMs */
|
|
#include <linux/modversions.h>
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/tty.h> /* console_print() interface */
|
|
|
|
/* Initialize the LKM */
|
|
int init_module()
|
|
{
|
|
console_print("Hello, world - this is the kernel speaking\n");
|
|
/* More normal is printk(), but there's less that can go wrong with
|
|
console_print(), so let's start simple.
|
|
*/
|
|
|
|
/* If we return a non zero value, it means that
|
|
* init_module failed and the LKM can't be loaded
|
|
*/
|
|
return 0;
|
|
}
|
|
|
|
|
|
/* Cleanup - undo whatever init_module did */
|
|
void cleanup_module()
|
|
{
|
|
console_print("Short is the life of an LKM\n");
|
|
}</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Compile this with the simple command
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>$ gcc -c -Wall -nostdinc -I /usr/src/linux/include hello.c</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>The <TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>-I</I
|
|
></TT
|
|
> above assumes that you have the source
|
|
code from which your base kernel (the base kernel of the kernel into
|
|
which you hope to load <TT
|
|
CLASS="LITERAL"
|
|
>hello.c</TT
|
|
>) was built in the
|
|
conventional spot, <TT
|
|
CLASS="FILENAME"
|
|
>/usr/src/linux</TT
|
|
>. If you're masochistic
|
|
enough to be using symbol versioning in your base kernel, then you
|
|
better have run 'make dep' on that kernel source too, because that's
|
|
what builds the .ver files that change the names of all your symbols.</P
|
|
><P
|
|
>But note that it's reasonably common <EM
|
|
>not</EM
|
|
> to have
|
|
the kernel headers installed there, and often, the
|
|
<EM
|
|
>wrong</EM
|
|
> headers are installed there. When you use
|
|
a kernel that you loaded from a distribution CD, you often have to
|
|
separately load the headers for it. To be safe, if you're playing
|
|
with compiling LKMs, you really should compile your own kernel, so you
|
|
know exactly what you're working with and can be absolutely sure
|
|
you're working with matching header files.</P
|
|
><P
|
|
>The <TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>-nostdinc</I
|
|
></TT
|
|
> option isn't strictly necessary,
|
|
but is the right thing to do. It will keep you out of trouble and
|
|
also remind you that the services of the standard C library, which you
|
|
may have melded in your mind with C itself, are not available to
|
|
kernel code. <TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>-nostdinc</I
|
|
></TT
|
|
> says not to include
|
|
"standard" directories in the include file search path.
|
|
This means, most notably, <TT
|
|
CLASS="FILENAME"
|
|
>/usr/include</TT
|
|
>.</P
|
|
><P
|
|
>The <TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>-c</I
|
|
></TT
|
|
> option says you just want to create an
|
|
object (.o) file, as opposed to gcc's default which is to create the
|
|
object file, then link it with a few other standard object files to
|
|
create something suitable for exec'ing in a user process. As you will
|
|
not be exec'ing this module but rather adding it to the kernel, that
|
|
link phase would be entirely inappropriate.</P
|
|
><P
|
|
><TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>-Wall</I
|
|
></TT
|
|
> (which makes the compiler warn you about
|
|
lots of kinds of questionable code) is obviously not necessary, but
|
|
this program should not generate any warnings. If it does, you need
|
|
to fix something.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN870"
|
|
></A
|
|
>11.2. Using the Kernel Build System</H2
|
|
><P
|
|
>Lkmpg contains fine instructions for building (compiling) an LKM
|
|
(except that the __KERNEL__ macro and usually the MODULE macro should
|
|
be defined in the source code instead of with
|
|
<TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>-D</I
|
|
></TT
|
|
> compiler options as Lkmpg suggests). But it
|
|
deserves mention that some Linux kernel programmers believe that the
|
|
only right way to build an LKM is to add it to a copy of the complete
|
|
Linux source tree and build it with the existing Linux make files
|
|
just like the LKMs that are part of Linux.</P
|
|
><P
|
|
>There are advantages to this. The biggest one is that when Linux
|
|
programmers change the way LKMs interface with the rest of the kernel
|
|
in a way that affects how you build an LKM, you're covered.</P
|
|
><P
|
|
>On the other hand, you will probably find from a code management point
|
|
of view that you really have to keep your own code and Linux separate,
|
|
and from a coding point of view, you really need to understand all the
|
|
intricacies of how your code gets compiled, especially when it
|
|
changes.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN876"
|
|
></A
|
|
>11.3. Rubini et al: Linux Device Drivers</H2
|
|
><P
|
|
>The most popular book on writing device drivers is O'Reilly's
|
|
<I
|
|
CLASS="CITETITLE"
|
|
>Linux Device Drivers</I
|
|
> by Alessandro
|
|
Rubini, Jonathan Corbet, and Greg Kroah-Hartman.</P
|
|
><P
|
|
>Even if you're writing an LKM that isn't a device driver, you can learn
|
|
a lot from this book that will help you.</P
|
|
><P
|
|
>The first edition of this book covers Linux 2.0, with notes about
|
|
differences in 2.2. The second edition (June 2001) covers Linux 2.4.
|
|
The third edition (April 2005) covers Linux 2.6. Of course, if you know
|
|
anything about Linux, you know that a book like this doesn't perfectly
|
|
cover any release, because Linux changes frequently. Linux 2.6 as was
|
|
current a month after the Third Edition was released had significant
|
|
differences from the Linux 2.6 about which the book was written.</P
|
|
><P
|
|
>The second edition of this book is available under the FDL. You can
|
|
read it at
|
|
<A
|
|
HREF="http://www.xml.com/ldd/chapter/book/"
|
|
TARGET="_top"
|
|
>http://www.xml.com/ldd/chapter/book/</A
|
|
>.
|
|
The third edition is available under the terms of the Creative Commons
|
|
Attribution-ShareAlike license, and you'll find it at
|
|
<A
|
|
HREF="http://lwn.net/Kernel/LDD3/"
|
|
TARGET="_top"
|
|
>http://lwn.net/Kernel/LDD3/</A
|
|
>.</P
|
|
><P
|
|
>This book is also available in print in any decent technical book store.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="USECOUNT"
|
|
></A
|
|
>11.4. Module Use Counts</H2
|
|
><P
|
|
>It is essential that the kernel not try to reference the code of a
|
|
module after it has been unloaded; i.e. you must not unload a module
|
|
while it is in use. An example of in use is a device driver for which
|
|
a device special file is open. Because there is an open file
|
|
descriptor for it, a user might do a read of the device and to execute
|
|
that read, the kernel would want to call a function that is in the
|
|
device driver. You can see that there would be a problem if you
|
|
unloaded that device driver module before the read -- the kernel would
|
|
reuse the memory that used to contain the read subroutine and there's
|
|
no telling what instructions the kernel would branch to when it thinks
|
|
it's calling the read subroutine.</P
|
|
><P
|
|
>In the original design, the LKM increments and decrements its use
|
|
count to tell the module manager whether it is OK to unload it. For
|
|
example, if it's a filesystem driver, it would increment the use count
|
|
when someone mounts a filesystem of the type it drives, and decrement
|
|
it at unmount time.</P
|
|
><P
|
|
>Later a more flexible alternative was added. Your LKM can register a
|
|
function that the module manager will call whenever it wants to know
|
|
if it is OK to unload the module. If the function returns a
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>true</TT
|
|
> value, that means the LKM is busy and cannot
|
|
be unloaded. If it returns a <TT
|
|
CLASS="LITERAL"
|
|
>false</TT
|
|
> value, the LKM
|
|
is idle and can be unloaded. The module manager holds the big kernel
|
|
lock from before calling the module-busy function until after its
|
|
cleanup subroutine returns or sleeps, and unless you've done something
|
|
odd, that should mean that your LKM cannot become busy between the
|
|
time that you report "not busy" and the time you clean up.</P
|
|
><P
|
|
>So how do you register the module-busy function? By putting its
|
|
address in the unfortunately named <TT
|
|
CLASS="VARNAME"
|
|
>can_unload</TT
|
|
> field
|
|
in the module descriptor ("struct module"). The name is truly
|
|
unfortunate because the boolean value it returns is the exact opposite
|
|
of what "can unload" means: true if the module manager
|
|
<EM
|
|
>cannot</EM
|
|
> unload the LKM.</P
|
|
><P
|
|
>The module manager ensures that it does not attempt to unload the
|
|
module before its initialization subroutine has returned or sleeps, so
|
|
you are safe in setting the <TT
|
|
CLASS="VARNAME"
|
|
>can_unload</TT
|
|
> field
|
|
anywhere in the initialization subroutine except after a sleep.</P
|
|
><P
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>can_unload</TT
|
|
> is little known and rarely used. Starting
|
|
with Linux 2.6, it no longer exists.</P
|
|
><P
|
|
>Whether you use traditional use counts of
|
|
<TT
|
|
CLASS="VARNAME"
|
|
>can_unload</TT
|
|
>, there are cases where you cannot be
|
|
sure that your module doesn't get unloaded while it is still in use.
|
|
If your LKM creates a kernel thread that executes LKM code, it is just
|
|
about impossible to be absolutely sure that thread is gone before the
|
|
LKM gets unloaded. There are various other kernel services that you
|
|
can give addresses within your LKM that won't properly let you know
|
|
when they have forgotten them.</P
|
|
><P
|
|
>The problem used to be worse than it is now. For example, it used to
|
|
be that if your LKM created a proc filesystem file, you couldn't stop
|
|
the LKM from getting unloaded while some process was executing your
|
|
read and write routines for the file. This and other instances of the
|
|
problem have been fixed by having code <EM
|
|
>outside</EM
|
|
>
|
|
the LKM understand that the address it's using might be in an LKM, and
|
|
therefore increment and decrement the use count as necessary. Where
|
|
this function is implemented, you often see a structure member named
|
|
"owner" which is a handle for the LKM (i.e. a struct module address).</P
|
|
><P
|
|
>These problems may be fixed in future version of Linux. Until then,
|
|
you can just cross your fingers. Some people believe these types of
|
|
problems are so hard to fix that the proper design for Linux is just
|
|
to make it impossible ever to unload an LKM. Starting with Linux 2.6,
|
|
the CONFIG_MODULE_UNLOAD kernel build configuration option determines
|
|
whether module unloading is allowed or not.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><HR><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="LINUXVERSIONS"
|
|
></A
|
|
>12. Differences Between Versions Of Linux</H1
|
|
><P
|
|
>One thing that deserves mention in this section is the variety of
|
|
Linux versions that exist in the world and what we call them. Unlike
|
|
a proprietary software product where one company carefully controls
|
|
the name and creates a small number of well defined releases,
|
|
variations of Linux are developed by lots of different independent
|
|
people and all of them are called Linux.</P
|
|
><P
|
|
>The most basic Linux releases are controlled by Linus Torvalds and
|
|
distributed by kernel.org as the main Linux releases. They are the
|
|
only releases that can properly by called "Linux 2.4," "Linux 2.6.6,"
|
|
etc.</P
|
|
><P
|
|
>But hardly anybody uses those releases. Instead, people start with
|
|
those releases and make modifications. People often sloppily refer to
|
|
a Linux based on Linux 2.6.6 as Linux 2.6.6 itself. But to be
|
|
correct, you have to add something -- usually a hyphen and a suffix.
|
|
Red Hat versions of Linux, which you see a lot, unfortunately use just
|
|
a plain number for that suffix, e.g. Linux 2.6.6-12. (It would be
|
|
better if they used something more explicitly Red Hat, such as Linux
|
|
2.6.6-rh12).</P
|
|
><P
|
|
>Remember that in this document, "Linux" means the kernel;
|
|
when we consider the operating systems called "Linux", the
|
|
situation gets even more complicated.</P
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN911"
|
|
></A
|
|
>12.1. Linux 2.4 - Linux 2.6</H2
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN913"
|
|
></A
|
|
>12.1.1. Linking Done In Kernel</H3
|
|
><P
|
|
>The biggest change to LKMs between Linux 2.4 and Linux 2.6 is an
|
|
internal one: LKMs get loaded much differently. Most people
|
|
won't see any difference except that the suffix on a file containing
|
|
an LKM has changed, because they use high level tools to manage
|
|
the LKMs and the interface to those tools hasn't changed.</P
|
|
><P
|
|
>Before Linux 2.6, a user space program would interpret the ELF object
|
|
(.o) file and do all the work of linking it to the running kernel,
|
|
generating a finished binary image. The program would pass that image
|
|
to the kernel and the kernel would do little more than stick it in
|
|
memory. In Linux 2.6, the kernel does the linking. A user space
|
|
program passes the contents of the ELF object file directly to the
|
|
kernel. For this to work, the ELF object image must contain
|
|
additional information. To identify this particular kind of ELF
|
|
object file, we name the file with suffix ".ko"
|
|
("kernel object") instead of ".o" For example,
|
|
the serial device driver that in Linux 2.4 lived in the file
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>serial.o</TT
|
|
> in Linux 2.6 lives in the file
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>serial.ko</TT
|
|
>.</P
|
|
><P
|
|
>So there is a whole new <SPAN
|
|
CLASS="APPLICATION"
|
|
>modutils</SPAN
|
|
> package
|
|
for use with Linux 2.6. In it, <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> is a trivial
|
|
program, as compared to the full blown linker of the Linux 2.4
|
|
version.</P
|
|
><P
|
|
>Also, the procedure to build an LKM is somewhat harder. To make a .ko
|
|
file, you start with a regular .o file. You run the program <B
|
|
CLASS="COMMAND"
|
|
>modpost</B
|
|
> (which comes with the Linux source code) on it to
|
|
create a C source file that describes the additional sections the .ko
|
|
file needs. We'll call this the .mod file because you conventionally
|
|
include ".mod" in the file name.</P
|
|
><P
|
|
>You compile the .mod file and link the result with the original .o
|
|
file to make a .ko file.</P
|
|
><P
|
|
>The .mod object file contains the name that the LKM instance will have
|
|
when you load the LKM. You set that name with a -D compile option
|
|
(when you compile the .mod file) that sets the KBUILD_MODNAME macro.</P
|
|
><P
|
|
>This change means some things are decidedly harder -- choosing the name for
|
|
the LKM instance, for example. In Linux 2.4, the name was one of the
|
|
inputs to the kernel. <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> decided on the name
|
|
and passed it to the kernel. <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
>'s -o option
|
|
told it explicitly what to use for the LKM instance name. But in 2.6,
|
|
there is no such parameter on the system call and hence no -o option
|
|
on <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
>. The name is part of the ELF object (.o
|
|
file) that you pass to the kernel. The default name is built into the
|
|
ELF object, but if you want to load it with some other name, you must
|
|
edit the ELF image before passing it to <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN931"
|
|
></A
|
|
>12.1.2. No Module Busy Function</H3
|
|
><P
|
|
>In Linux 2.6 <TT
|
|
CLASS="VARNAME"
|
|
>can_unload</TT
|
|
> (see <A
|
|
HREF="#USECOUNT"
|
|
>Section 11.4</A
|
|
>) is gone.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN936"
|
|
></A
|
|
>12.1.3. CONFIG_MODULE_UNLOAD</H3
|
|
><P
|
|
>You can configure the kernel build to build a kernel that does not
|
|
allow unloading of modules at all, thus sidestepping any problems with
|
|
modules that get unloaded while still in use. See <A
|
|
HREF="#USECOUNT"
|
|
>Section 11.4</A
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN940"
|
|
></A
|
|
>12.1.4. Reference Counting</H3
|
|
><P
|
|
>The interface that the code of an LKM uses to manipulate its reference
|
|
count has been replaced.</P
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><HR><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="COPYRIGHT"
|
|
></A
|
|
>13. Copyright Considerations With LKMs</H1
|
|
><P
|
|
>A perennial question about LKMs is whether the terms of GPL apply to
|
|
one, considering that the Linux kernel is distributed under GPL. For
|
|
example, is it OK to ship an LKM in binary only form? This section
|
|
covers the copyright issues surrounding LKMs, which are as interesting
|
|
as they are complex. Fair warning: we don't reach a conclusion. The
|
|
law is unsettled and there are plenty of good but conflicting
|
|
arguments.</P
|
|
><P
|
|
>Remember that countries have varying copyright laws, so even if you
|
|
figure out the answer to a question in one country, it might be
|
|
different in another. But copyright laws are actually remarkably
|
|
similar, and this section won't go into the matter in enough detail
|
|
that it will really make a difference.</P
|
|
><P
|
|
>Let's start at the beginning and look at what a copyright is.</P
|
|
><P
|
|
>Primarily, a copyright is a person's right to stop other people from
|
|
copying something. It is a legal right, not a moral one. That means
|
|
it is created by law to bring about some practical effect, rather than
|
|
something that people believe people are naturally entitled to.</P
|
|
><P
|
|
>The primary effect that copyright seeks to bring about is that an author gets
|
|
paid for what he created. Some people believe that is a valid goal
|
|
itself, because an author has a natural right to the value that he
|
|
creates. But historically, that isn't the real goal of copyright.
|
|
The real goal is secondary to making the author get paid for his work:
|
|
It causes the author to create in the first place. An author is more
|
|
likely to spend time and money writing if he will get paid for it.</P
|
|
><P
|
|
>The actual operation of copyright law achieves that goal only
|
|
approximately. We've all seen cases where the law is used to transfer
|
|
wealth in ways that don't contribute to that goal at all. For
|
|
example, a music publisher denies a person permission to copy a song
|
|
that he wouldn't have paid for anyway. Legislators think of that as
|
|
collateral damage -- what copyright law does to cause things to get
|
|
written makes up for the senseless copy restrictions in other cases.</P
|
|
><P
|
|
>But when it comes to LKMs, there is another, much more complex area of
|
|
copyright law that matters: derivative works. Copyright law gives an
|
|
author the right to stop someone from creating a derivative work. A
|
|
derivative work is <EM
|
|
>not</EM
|
|
> a copy of anything the
|
|
author wrote. So what is it?</P
|
|
><P
|
|
>The definition of derivative work is elusive, but here are some
|
|
examples: When you translate a book from English into French, the
|
|
French version is a derivative work of the English work. If you write
|
|
a new chapter for a novel, your new chapter is a derivative work of
|
|
the novel. If you write a whole new book for the Harry Potter series,
|
|
with the same characters and settings, that is a derivative work of
|
|
all the Harry Potter books. If you draw a Dilbert cartoon you thought
|
|
of on a birthday card, that is a derivative work of all the Dilbert
|
|
strips, books, etc.</P
|
|
><P
|
|
>And this brings us to LKMs, because many people believe that an LKM is
|
|
a derivative work of the Linux kernel. The Free Software Foundation
|
|
has said so. Linus Torvalds has said it is sometimes. No court of
|
|
law has ever ruled one way or the other.</P
|
|
><P
|
|
>Now let's turn to the copyright on Linux. For the sake of discussion,
|
|
when we say "Linux," we will mean the contents of the
|
|
tarball you download from kernel.org as the regular Linux kernel.</P
|
|
><P
|
|
>Who owns the copyright on Linux? Lots of people. Nearly everyone who
|
|
has contributed code to Linux reserved his own copyright. Some of
|
|
that work was done for hire and therefore the employing corporations
|
|
own the copyright. Linus Torvalds is the most visible copyright
|
|
owner, but he holds copyright on a very small part of Linux.</P
|
|
><P
|
|
>How do these people prosecute their copyright? Well, nobody makes
|
|
deals with them to purchase copying rights. It wouldn't be practical.
|
|
However, they all offer a copyright license -- the same one -- to the
|
|
public. The license is documented and offered in a file in the
|
|
tarball, and is known as the General Public License (GPL). GPL is not
|
|
specific to Linux. It was developed by the Free Software Foundation
|
|
before Linux existed, and was simply chosen by Linus back when he was
|
|
the only copyright owner. And Linus doesn't put any code into the
|
|
tarball without the author offering the same license.</P
|
|
><P
|
|
>A copyright license is permission by a copyright owner to do something
|
|
that he has a legal right to stop you from doing, such as make a copy
|
|
or a derivative work. What it means to be a public license is that it
|
|
is offered to the public, as opposed to the copyright owner offering
|
|
it to particular persons he knows about.</P
|
|
><P
|
|
>The GPL lets you do almost anything with the code -- it's almost like
|
|
the copyright owners waiving all their copyright rights. But not
|
|
quite: there are strings attached. The license has conditions. In
|
|
order to have the permission, you have to meet the conditions. The
|
|
condition we care about here is one of two things, or both, depending
|
|
on how you read the license document (the document is ambiguous).
|
|
Either a) if you distribute a derivative work of Linux, you
|
|
have to supply source code for the whole derivative work; or b) if you
|
|
distribute a work containing Linux, you have to supply source code for
|
|
the entire work.</P
|
|
><P
|
|
>Now we come to the real question: what sort of rights do you have to
|
|
distribute an LKM you wrote?</P
|
|
><P
|
|
>Certainly, many people believe that you can distribute an LKM under
|
|
any terms you like, including binary-only and the owners of the Linux
|
|
copyright have nothing to say about it. You're distributing nothing
|
|
but your own code. And it's not a derivative work of anything. Many
|
|
people do distribute binary-only LKMs and believe that a principle
|
|
benefit of LKMs is the ability to do that.</P
|
|
><P
|
|
>Others think differently: The LKM, while an original work, is a
|
|
derivative work of Linux. The Linux copyright owners have the right
|
|
to control distribution. The only permission they gave you to
|
|
distribute it is GPL, and that permission is only under the condition
|
|
that you supply source code.</P
|
|
><P
|
|
>Let's look a little closer at the issue of whether an LKM is a
|
|
derivative work of Linux. The argument in favor goes that writing an
|
|
LKM is like writing a supplemental chapter for a novel. We know the
|
|
latter is creating a derivative work. The LKM is like the chapter
|
|
because it's specifically designed to be part of a whole with the
|
|
existing Linux kernel. It has no use in any other context, and when
|
|
deployed, is tightly woven into the rest of Linux. The fact that you
|
|
typically use a bunch of Linux header files to compile it is proof
|
|
that it's just an extension of Linux (don't confuse this with another
|
|
argument -- that the #include actually means you're distributing that
|
|
header file inside your object code). And note that a kernel module
|
|
loaded at run time is essentially the same program you would
|
|
statically bind into the base kernel if you chose to go that route.
|
|
If writing a module for the Linux source tree is creating a derivative
|
|
work, then so must be writing an LKM. LKMs often have to be updated
|
|
to conform to updates the base kernel.</P
|
|
><P
|
|
>Wasabi Systems, a company that sells kernels with freer licensing than
|
|
Linux, has published <A
|
|
HREF="http://www.wasabisystems.com/gpl/lkm.html"
|
|
TARGET="_top"
|
|
>a paper</A
|
|
> that
|
|
argues in more detail that LKMs are derivative works of Linux and you
|
|
should therefore be wary of publishing binary-only LKMs for it.</P
|
|
><P
|
|
>The argument against says that an LKM is something that interacts with
|
|
Linux, not something that is part of Linux. It likens the LKM to a
|
|
user space program, communicating with the kernel via system calls,
|
|
or an FTP client program (which would not be a derivative work of any
|
|
FTP server program).</P
|
|
><P
|
|
>The issue also runs into one of those areas where books and computer
|
|
programs aren't analogous because a computer program does something,
|
|
whereas a book just communicates an idea to a person. Loading an LKM
|
|
might be more like plugging an attachment into your vacuum cleaner
|
|
than like inserting pages into your book. And we know that the
|
|
blueprints for a vacuum cleaner attachment are not a derivative work
|
|
of the blueprints for a vacuum cleaner.</P
|
|
><P
|
|
>So that's as far as I can go. There appears to be a matter of degree
|
|
here and a judge will have to draw a line somewhere.</P
|
|
><P
|
|
>But if you need to make a practical decision, consider that there have
|
|
been well-known binary LKMs (drivers for Nvidia video adapters seem
|
|
to be the most famous) for years and no one has sued for copyright
|
|
infringement. Also, Linus Torvalds, influential for reasons other than
|
|
legal, has said binary-only LKMs are OK with him.</P
|
|
><P
|
|
>What about GPL-ONLY symbols? Kernel developers have selected some
|
|
symbols that one uses in interfacing an LKM to the base kernel as
|
|
GPL-only. These symbols have "GPL_ONLY" in their names,
|
|
making this intent obvious. Furthermore, in order for the Linux
|
|
module loader to let your LKM use them, you must include some code in
|
|
your LKM that supposedly certifies you license your module under GPL.</P
|
|
><P
|
|
>These probably have no legal significance. If the LKM is not a
|
|
derivative work of Linux, then the kernel developers simply have no
|
|
legal way to block you from putting the GPL annotation in your code
|
|
and distributing it binary-only anyhow. If the LKM
|
|
<EM
|
|
>is</EM
|
|
> a derivative work of Linux, then the absence
|
|
of the GPL-only classification of the symbol is probably not enough to
|
|
give permission to use it in a binary-only LKM. The license document
|
|
does not mention them. At best, you can use GPL-only symbols as a
|
|
gentleman's promise not to sue you for use of all the other symbols in
|
|
a binary-only LKM.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><HR><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN973"
|
|
></A
|
|
>14. Related Documentation</H1
|
|
><P
|
|
>For modules that are part of Linux (i.e. distributed with the base
|
|
kernel), you can sometimes find documentation in the <TT
|
|
CLASS="FILENAME"
|
|
>Documentation</TT
|
|
> subdirectory of the Linux
|
|
source code.</P
|
|
><P
|
|
>Many LKMs can be alternatively bound into the base kernel. If you do
|
|
that, you will pass parameters to them via the kernel "command line,"
|
|
which in its most basic form means via a prompt at boot time.
|
|
<I
|
|
CLASS="CITETITLE"
|
|
>The BootPrompt HOWTO</I
|
|
> by Paul Gortmaker
|
|
<TT
|
|
CLASS="EMAIL"
|
|
><<A
|
|
HREF="mailto:Paul.Gortmaker@anu.edu.au"
|
|
>Paul.Gortmaker@anu.edu.au</A
|
|
>></TT
|
|
> will help you with that. It
|
|
is available from the <A
|
|
HREF="http://www.tldp.org"
|
|
TARGET="_top"
|
|
>Linux
|
|
Documentation Project</A
|
|
>.</P
|
|
><P
|
|
>Don't forget that the source code of Linux and any LKM is always the
|
|
documentation of last resort, and the most trustworthy.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><HR><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="INDIVIDUAL"
|
|
></A
|
|
>15. Individual Modules</H1
|
|
><P
|
|
>In this chapter, I document individual LKMs. Where possible, I do this
|
|
by reference to more authoritative documentation for the particular LKM
|
|
(probably maintained by the same person who maintains the LKM code).</P
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN985"
|
|
></A
|
|
>15.1. Executable Interpreters</H2
|
|
><P
|
|
>You must have at least one executable interpreter bound into the
|
|
base kernel, because in order to load an executable interpreter LKM,
|
|
you have to run an executable and something has to interpret that
|
|
executable.</P
|
|
><P
|
|
>That one bound-in executable interpreter is almost certainly the ELF
|
|
interpreter, since virtually all executables in a Linux system are
|
|
ELF.</P
|
|
><P
|
|
>Historical note: Before ELF existed on Linux (c. 1995), the normal
|
|
executable format was a.out. For a while, part ELF/part a.out
|
|
systems were common. Some still exist.</P
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN990"
|
|
></A
|
|
>15.1.1. binfmt_aout: executable interpreter for a.out format</H3
|
|
><P
|
|
>a.out is the venerable executable format that was common in Unix's
|
|
early history and originally Linux's only executable format. To this
|
|
day, the default name of the executable output file of the GNU
|
|
compiler is <TT
|
|
CLASS="FILENAME"
|
|
>a.out</TT
|
|
> (regardless of what it's format
|
|
is).</P
|
|
><P
|
|
>If you try to run an a.out executable without this, your
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>exec</TT
|
|
> system call fails with a "cannot execute
|
|
binary file" error.</P
|
|
><P
|
|
>There are no LKM parameters.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe binfmt_aout</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN999"
|
|
></A
|
|
>15.1.2. binfmt_elf: executable interpreter for ELF format</H3
|
|
><P
|
|
>ELF is the normal executable format on Linux systems.</P
|
|
><P
|
|
>It's almost inconceivable that you wouldn't have this executable
|
|
interpreter bound into the base kernel (if for no other reason that
|
|
your <B
|
|
CLASS="COMMAND"
|
|
>insmod</B
|
|
> is probably an ELF executable).
|
|
However, it is conceptually possible to leave it out of the base
|
|
kernel and insert it as an LKM.</P
|
|
><P
|
|
>There are no LKM parameters.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe binfmt_elf</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1007"
|
|
></A
|
|
>15.1.3. binfmt_java: executable interpreter for Java bytecode</H3
|
|
><P
|
|
>Java is a relatively modern object oriented programming language.
|
|
Java programs are traditionally compiled into "Java bytecode" which is
|
|
meant to be interpreted by a Java bytecode interpreter. The point of
|
|
this new object language is that the bytecode object files are
|
|
portable: Although different systems require different object formats,
|
|
as long as each system has a bytecode interpreter, it can run bytecode
|
|
object files. (This only works for a while, of course. If
|
|
portability were that easy, all systems today would use the same
|
|
object format anyway).</P
|
|
><P
|
|
>While the intent was that the bytecode interpreter would run as a user
|
|
space program, with this LKM you can make the Linux kernel interpret
|
|
Java bytecode like any other executable format. So you can run a
|
|
program compiled from Java the same as you would run a program
|
|
compiled from C (e.g. type its name at a command shell prompt).</P
|
|
><P
|
|
>In practice, the advantages of the intermediate bytecode language have
|
|
not been proven and it is quite common to compile Java directly to a
|
|
more traditional executable format, such as ELF. If you do that, you
|
|
don't need <B
|
|
CLASS="COMMAND"
|
|
>binfmt_java</B
|
|
>.</P
|
|
><P
|
|
>There are no LKM parameters.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe binfmt_java</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN1016"
|
|
></A
|
|
>15.2. Block Device Drivers</H2
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1018"
|
|
></A
|
|
>15.2.1. floppy: floppy disk driver</H3
|
|
><P
|
|
>This is the device driver for floppy disks. You need this in order to
|
|
access a floppy disk in any way.</P
|
|
><P
|
|
>This LKM is documented in the file <TT
|
|
CLASS="FILENAME"
|
|
>README.fd</TT
|
|
> in
|
|
the <TT
|
|
CLASS="FILENAME"
|
|
>linux/drivers/block
|
|
directory</TT
|
|
> of the Linux source tree. For detailed up to date
|
|
information refer directly to this file.</P
|
|
><P
|
|
>Note that if you boot (or might boot) from a floppy disk or with a
|
|
root filesystem on a floppy disk, you must have this driver bound into
|
|
the base kernel, because your system will need it before it has a
|
|
chance to insert the LKM.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>
|
|
modprobe floppy 'floppy="daring two_fdc 0,thinkpad 0x8,fifo_depth"'</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There is only one LKM parameter: <TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>floppy</I
|
|
></TT
|
|
>. But
|
|
it contains many subparameters. The reason for this unusual parameter
|
|
format is to be consistent with the way you would specify the same
|
|
things in the kernel boot parameters if the driver were bound into the
|
|
base kernel.</P
|
|
><P
|
|
>The value of <TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>floppy</I
|
|
></TT
|
|
> is a sequence of
|
|
blank-delimited words. Each of those words is one of the following
|
|
sequences of comma-delimited words:</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>asus_pci</DT
|
|
><DD
|
|
><P
|
|
> Sets the bit mask of allowed drives to allow only units 0 and
|
|
1. Obsolete, as this is the default setting anyways
|
|
</P
|
|
></DD
|
|
><DT
|
|
>daring</DT
|
|
><DD
|
|
><P
|
|
> Tells the floppy driver that you have a well behaved floppy
|
|
controller. This allows more efficient and smoother
|
|
operation, but may fail on certain controllers. This may
|
|
speed up certain operations.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>0,daring</DT
|
|
><DD
|
|
><P
|
|
> Tells the floppy driver that your floppy controller should be used
|
|
with caution.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>one_fdc</DT
|
|
><DD
|
|
><P
|
|
> Tells the floppy driver that you have only floppy controller
|
|
(default).
|
|
</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>address</TT
|
|
>,two_fdc</DT
|
|
><DD
|
|
><P
|
|
> Tells the floppy driver that you have two floppy
|
|
controllers. The second floppy controller is assumed to be
|
|
at <TT
|
|
CLASS="VARNAME"
|
|
>address</TT
|
|
>. This option is not needed if
|
|
the second controller is at address 0x370, and if you use
|
|
the 'cmos' option
|
|
</P
|
|
></DD
|
|
><DT
|
|
>two_fdc</DT
|
|
><DD
|
|
><P
|
|
> Like above, but with default address
|
|
</P
|
|
></DD
|
|
><DT
|
|
>thinkpad</DT
|
|
><DD
|
|
><P
|
|
> Tells the floppy driver that you have an IBM Thinkpad model
|
|
notebook computer. Thinkpads use an inverted convention for
|
|
the disk change line.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>0,thinkpad</DT
|
|
><DD
|
|
><P
|
|
> Tells the floppy driver that you don't have a Thinkpad.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>nodma</DT
|
|
><DD
|
|
><P
|
|
> Tells the floppy driver not to use DMA for data transfers.
|
|
This is needed on HP Omnibooks, which don't have a workable
|
|
DMA channel for the floppy driver. This option is also
|
|
useful if you frequently get "Unable to allocate DMA
|
|
memory" messages. Indeed, DMA memory needs to be
|
|
continuous in physical memory, and is thus harder to find,
|
|
whereas non-DMA buffers may be allocated in virtual
|
|
memory. However, I advise against this if you have an FDC
|
|
without a FIFO (8272A or 82072). 82072A and later are
|
|
OK). You also need at least a 486 to use nodma. If you use
|
|
nodma mode, I suggest you also set the FIFO threshold to 10
|
|
or lower, in order to limit the number of data transfer
|
|
interrupts.
|
|
</P
|
|
><P
|
|
> If you have a FIFO-able FDC, the floppy driver
|
|
automatically falls back on non DMA mode if it can't find
|
|
any DMA-able memory. If you want to avoid this, explicitly
|
|
specify "yesdma".
|
|
</P
|
|
></DD
|
|
><DT
|
|
>omnibook</DT
|
|
><DD
|
|
><P
|
|
> Same as <TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>nodma</I
|
|
></TT
|
|
>.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>yesdma</DT
|
|
><DD
|
|
><P
|
|
> Tells the floppy driver that a workable DMA channel is available
|
|
(the default).
|
|
</P
|
|
></DD
|
|
><DT
|
|
>nofifo</DT
|
|
><DD
|
|
><P
|
|
> Disables the FIFO entirely. This is needed if you get "Bus
|
|
master arbitration error" messages from your Ethernet card (or
|
|
from other devices) while accessing the floppy.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>fifo</DT
|
|
><DD
|
|
><P
|
|
> Enables the FIFO (default)
|
|
</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>threshold</TT
|
|
>,fifo_depth</DT
|
|
><DD
|
|
><P
|
|
> Sets the FIFO threshold. This is mostly relevant in DMA
|
|
mode. If this is higher, the floppy driver tolerates more
|
|
interrupt latency, but it triggers more interrupts (i.e. it
|
|
imposes more load on the rest of the system). If this is
|
|
lower, the interrupt latency should be lower too (faster
|
|
processor). The benefit of a lower threshold is fewer
|
|
interrupts.
|
|
</P
|
|
><P
|
|
> To tune the fifo threshold, switch on over/underrun
|
|
messages using 'floppycontrol --messages'. Then access a
|
|
floppy disk. If you get a huge amount of "Over/Underrun -
|
|
retrying" messages, then the fifo threshold is too low.
|
|
Try with a higher value, until you only get an occasional
|
|
Over/Underrun.
|
|
</P
|
|
><P
|
|
> The value must be between 0 and 0xf, inclusive.
|
|
</P
|
|
><P
|
|
> As you insert and remove the LKM to try different values,
|
|
remember to redo the 'floppycontrol --messages' every time
|
|
you insert the LKM. You shouldn't normally have to tune
|
|
the fifo, because the default (0xa) is reasonable.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>drive</TT
|
|
>,<TT
|
|
CLASS="VARNAME"
|
|
>type</TT
|
|
>,cmos</DT
|
|
><DD
|
|
><P
|
|
> Sets the CMOS type of <TT
|
|
CLASS="VARNAME"
|
|
>drive</TT
|
|
> to
|
|
<TT
|
|
CLASS="VARNAME"
|
|
>type</TT
|
|
>. This is mandatory if you have
|
|
more than two floppy drives (only two can be described in
|
|
the physical CMOS), or if your BIOS uses non-standard CMOS
|
|
types. The CMOS types are:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>0</DT
|
|
><DD
|
|
><P
|
|
> Use the value of the physical CMOS
|
|
</P
|
|
></DD
|
|
><DT
|
|
>1</DT
|
|
><DD
|
|
><P
|
|
>5 1/4 DD</P
|
|
></DD
|
|
><DT
|
|
>2</DT
|
|
><DD
|
|
><P
|
|
>5 1/4 HD</P
|
|
></DD
|
|
><DT
|
|
>3</DT
|
|
><DD
|
|
><P
|
|
>3 1/2 DD</P
|
|
></DD
|
|
><DT
|
|
>4</DT
|
|
><DD
|
|
><P
|
|
>3 1/2 HD</P
|
|
></DD
|
|
><DT
|
|
>5</DT
|
|
><DD
|
|
><P
|
|
>3 1/2 ED</P
|
|
></DD
|
|
><DT
|
|
>6</DT
|
|
><DD
|
|
><P
|
|
>3 1/2 ED</P
|
|
></DD
|
|
><DT
|
|
>16</DT
|
|
><DD
|
|
><P
|
|
>unknown or not installed</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
>
|
|
</P
|
|
><P
|
|
> (Note: there are two valid types for ED drives. This is
|
|
because 5 was initially chosen to represent floppy
|
|
<EM
|
|
>tapes</EM
|
|
>, and 6 for ED drives. AMI
|
|
ignored this, and used 5 for ED drives. That's why the
|
|
floppy driver handles both)
|
|
</P
|
|
></DD
|
|
><DT
|
|
>unexpected_interrupts</DT
|
|
><DD
|
|
><P
|
|
> Print a warning message when an unexpected interrupt is received.
|
|
(default behavior)
|
|
</P
|
|
></DD
|
|
><DT
|
|
>no_unexpected_interrupts</DT
|
|
><DD
|
|
><P
|
|
> Don't print a message when an unexpected interrupt is
|
|
received. This is needed on IBM L40SX laptops in certain
|
|
video modes. (There seems to be an interaction between
|
|
video and floppy. The unexpected interrupts only affect
|
|
performance, and can safely be ignored.)
|
|
</P
|
|
></DD
|
|
><DT
|
|
>L40SX</DT
|
|
><DD
|
|
><P
|
|
> Same as <TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>no_unexpected_interrupts</I
|
|
></TT
|
|
>.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>broken_dcl</DT
|
|
><DD
|
|
><P
|
|
> Don't use the disk change line, but assume that the disk
|
|
was changed whenever the device node is reopened. Needed
|
|
on some boxes where the disk change line is broken or
|
|
unsupported. This should be regarded as a stopgap measure,
|
|
indeed it makes floppy operation less efficient due to
|
|
unneeded cache flushings, and slightly more unreliable.
|
|
Please verify your cable, connection and jumper settings if
|
|
you have any DCL problems. However, some older drives, and
|
|
also some laptops are known not to have a DCL.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>debug</DT
|
|
><DD
|
|
><P
|
|
> Print debugging messages
|
|
</P
|
|
></DD
|
|
><DT
|
|
>messages</DT
|
|
><DD
|
|
><P
|
|
> Print informational messages for some operations (disk change
|
|
notifications, warnings about over and underruns, and about
|
|
autodetection)
|
|
</P
|
|
></DD
|
|
><DT
|
|
>silent_dcl_clear</DT
|
|
><DD
|
|
><P
|
|
> Uses a less noisy way to clear the disk change line (which
|
|
doesn't involve seeks). Implied by daring.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>nr</TT
|
|
>,irq</DT
|
|
><DD
|
|
><P
|
|
> Tells the driver to expect interrupts on IRQ
|
|
<TT
|
|
CLASS="VARNAME"
|
|
>nr</TT
|
|
> instead of the conventional IRQ 6.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>nr</TT
|
|
>,dma</DT
|
|
><DD
|
|
><P
|
|
> Tells the driver to use DMA channel <TT
|
|
CLASS="VARNAME"
|
|
>nr</TT
|
|
>
|
|
instead of the
|
|
conventional DMA channel 2.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>slow</DT
|
|
><DD
|
|
><P
|
|
> Use PS/2 stepping rate: PS/2 floppies have much slower step
|
|
rates than regular floppies. It's been recommended that
|
|
take about 1/4 of the default speed in some more extreme
|
|
cases.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>mask</TT
|
|
>,allowed_drive_mask</DT
|
|
><DD
|
|
><P
|
|
> Sets the bitmask of allowed drives to <TT
|
|
CLASS="VARNAME"
|
|
>mask</TT
|
|
>.
|
|
By default,
|
|
only units 0 and 1 of each floppy controller are allowed.
|
|
This is done because certain non-standard hardware (ASUS
|
|
PCI motherboards) mess up the keyboard when accessing units
|
|
2 or 3. This option is somewhat obsoleted by the 'cmos'
|
|
option.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>all_drives</DT
|
|
><DD
|
|
><P
|
|
> Sets the bitmask of allowed drives to all drives. Use this
|
|
if you have more than two drives connected to a floppy
|
|
controller.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1194"
|
|
></A
|
|
>15.2.2. loop: loop device driver</H3
|
|
><P
|
|
>This module lets you mount a filesystem that is stored in a regular
|
|
file (in another filesystem). That other file is called the backing file.</P
|
|
><P
|
|
>One use of this is to test an ISO 9660 filesystem before irreversibly
|
|
burning it onto a CD. You build the filesystem in a 650 MB regular
|
|
file. That file will be the input to the CD burning program. But you
|
|
can define a loopback device based on that file as backing file and
|
|
then mount the filesystem right from the backing file.</P
|
|
><P
|
|
>It can also
|
|
give you a handy way to transmit collections of files over a network.
|
|
It's like a tar file, only you don't have to pack and unpack it -- you
|
|
just mount the original file.</P
|
|
><P
|
|
>Some people use loop devices on a machine that sometimes runs Windows
|
|
and sometimes runs Linux to allow them to maintain the Linux system
|
|
via the Windows system: put a Linux root filesystem in a file in a FAT
|
|
filesystem that Windows can access, then mount the Linux root
|
|
filesystem via a loop device when Linux is running.</P
|
|
><P
|
|
>You can keep the filesystem encrypted or compressed, or encoded in any
|
|
arbitrary way, in the backing file. The loop device encodes (e.g. encrypts)
|
|
as you write to it, and decodes (e.g. decrypts) as you read. (An
|
|
alternative more popular strategy for encrypting and compressing a
|
|
filesystem is to use an encrypted or compressed filesystem type,
|
|
either a native one or one backed by a normal filesystem. Cfs, Tcfs,
|
|
and Stegfs are examples of such filesystem types).</P
|
|
><P
|
|
>An encoding system is based on a "transfer function". There
|
|
are two tranfer functions built into the <TT
|
|
CLASS="FILENAME"
|
|
>loop</TT
|
|
> module: the
|
|
identify transfer function (which is for the normal no-encoding case
|
|
-- What you see in the loop device is exactly what is in the backing
|
|
file) and a simple XOR encryption function. A separate kernel module
|
|
can add any transfer function by calling the <TT
|
|
CLASS="FILENAME"
|
|
>loop</TT
|
|
>
|
|
module's exported <TT
|
|
CLASS="LITERAL"
|
|
>loop_register_transfer()</TT
|
|
> function.</P
|
|
><P
|
|
>There appear to be various modules floating around
|
|
that provide transfer functions to do compression and encryption (DES,
|
|
IDEA, Fish, etc.).
|
|
Some of them appear to be part of current Linux kernel distributions.
|
|
In addition, there appear to be various alternative loop device drivers,
|
|
many of them also called <TT
|
|
CLASS="FILENAME"
|
|
>loop</TT
|
|
>, that have such transfer
|
|
functions built in.</P
|
|
><P
|
|
>Do not confuse these loop devices with the "loopback device"
|
|
used for network connections from the machine to itself. That isn't
|
|
actually a device at all - it's a network interface.</P
|
|
><P
|
|
>This module is a block device driver. You set up a loop device by
|
|
issuing an ioctl to it to bind a file to it. The typical program to
|
|
issue this ioctl is <B
|
|
CLASS="COMMAND"
|
|
>losetup</B
|
|
>. See the documentation
|
|
of <B
|
|
CLASS="COMMAND"
|
|
>losetup</B
|
|
> for more details. There are also options
|
|
on the normal 'mount' command to do loop device setup under the covers,
|
|
but because that confuses the logically separate operations of setting
|
|
up a loop device and mounting a filesystem, for the sake of clarity
|
|
you're probably better off using <B
|
|
CLASS="COMMAND"
|
|
>losetup</B
|
|
>.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe loop</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Module Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>max_loop</DT
|
|
><DD
|
|
><P
|
|
>Number of loop devices that will exist. Contrary to what its
|
|
name suggests, the number you specify is the number of loop
|
|
devices that always exist. An existing device is not
|
|
necessarily configured (bound to a backing file), though,
|
|
so this number can be thought of as the maximum number of
|
|
loop devices that you can configure.
|
|
</P
|
|
><P
|
|
>The minor numbers for these loop devices are consecutive
|
|
starting at 0.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>There is more information on loop devices in the Loopback Encrypted Filesystem HOWTO and the Loopback Root Filesystem HOWTO and the manual for <B
|
|
CLASS="COMMAND"
|
|
>losetup</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1223"
|
|
></A
|
|
>15.2.3. linear: linear (non-RAID) disk array device driver</H3
|
|
><P
|
|
>This driver lets you combine several disk partitions into one
|
|
logical block device.</P
|
|
><P
|
|
>If you use this, then your multiple devices driver will be able to use
|
|
the so-called linear mode, i.e. it will combine the disk
|
|
partitions by simply appending one to the other.</P
|
|
><P
|
|
>See <I
|
|
CLASS="CITETITLE"
|
|
>Software-RAID-HOWTO</I
|
|
>.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe linear</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1232"
|
|
></A
|
|
>15.2.4. raid0: RAID-0 device driver</H3
|
|
><P
|
|
>This driver lets you combine several disk partitions into one logical
|
|
block device.</P
|
|
><P
|
|
>If you use this, then your multiple devices driver will be able to use
|
|
the so-called raid0 mode, i.e. it will combine the disk partitions
|
|
into one logical device in such a fashion as to fill them up evenly,
|
|
one chunk here and one chunk there. This will increase the throughput
|
|
rate if the partitions reside on distinct disks.</P
|
|
><P
|
|
>See <I
|
|
CLASS="CITETITLE"
|
|
>Software-RAID-HOWTO</I
|
|
>.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe raid0</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1241"
|
|
></A
|
|
>15.2.5. rd: ramdisk device driver</H3
|
|
><P
|
|
>A ramdisk is a block device whose storage is composed of system memory
|
|
(real memory; not virtual). You can use it like a very fast disk
|
|
device and also in circumstances where you need a device, but don't
|
|
have traditional hardware devices to play with.</P
|
|
><P
|
|
>A common example of the latter is for a rescue system -- a system
|
|
you use to diagnose and repair your real system. Since you don't
|
|
want to mess with your real disks, you run off ramdisks. You might
|
|
load data into these ramdisks from external media such as floppy
|
|
disks.</P
|
|
><P
|
|
>Sometimes, you have your boot loader (e.g. <B
|
|
CLASS="COMMAND"
|
|
>lilo</B
|
|
>)
|
|
create a ramdisk and load it with data (perhaps from a floppy disk).
|
|
Of course, if you do this, you cannot use the LKM version of the
|
|
ramdisk driver because the driver will have to be in the kernel at
|
|
boot time.</P
|
|
><P
|
|
>A ramdisk is actually conceptually simple in Linux. Disk devices
|
|
operate through memory because of the buffer cache. The only
|
|
difference with a ramdisk is that you never actually get past the
|
|
buffer cache to a real device. This is because with a ramdisk, 1)
|
|
when you first access a particular block, Linux just assumes it is
|
|
all zeroes; and 2) the device's buffer cache blocks are never
|
|
written to the device, ergo never stolen for use with other devices.
|
|
This means reads and writes are always to the buffer cache and never
|
|
reach the device.</P
|
|
><P
|
|
>There is additional information about ramdisks in the file
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>Documentation/ramdisk.txt</TT
|
|
> in the Linux source
|
|
tree.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> modprobe rd</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters that you can supply to the LKM, but
|
|
if you bind the module into the base kernel, there are kernel parameters
|
|
you can pass to it. See <I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1254"
|
|
></A
|
|
>15.2.6. xd: XT disk device driver</H3
|
|
><P
|
|
>Very old 8 bit hard disk controllers used in the IBM XT computer. No,
|
|
the existence of XT disk support does NOT mean that you can run Linux
|
|
on an IBM XT :).</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe xd</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="SCSI"
|
|
></A
|
|
>15.3. SCSI Drivers</H2
|
|
><P
|
|
>Detailed information about SCSI drivers is in
|
|
<I
|
|
CLASS="CITETITLE"
|
|
>SCSI-2.4-HOWTO</I
|
|
>.</P
|
|
><P
|
|
>Linux's SCSI function is implemented in three layers, and there are
|
|
LKMs for all of them.</P
|
|
><P
|
|
>In the middle is the mid-level driver or SCSI core. This consists of
|
|
the <B
|
|
CLASS="COMMAND"
|
|
>scsi_mod</B
|
|
> LKM. It does all those things that
|
|
are common among SCSI devices regardless of what SCSI adapter you use
|
|
and what class of device (disk, scanner, CD-ROM drive, etc.) it is.</P
|
|
><P
|
|
>There is a low-level driver for each kind of SCSI adapter --
|
|
typically, a different driver for each brand. For example, the
|
|
low-level driver for Advansys adapters (made by the company which is
|
|
now Connect.com) is named <B
|
|
CLASS="COMMAND"
|
|
>advansys</B
|
|
>. (If you are
|
|
comparing ATA (aka IDE) and SCSI disk devices, this is a major
|
|
difference -- ATA is simple and standard enough that one driver works
|
|
with all adapters from all companies. SCSI is less standard and as a
|
|
result you should have less confidence in any particular adapter being
|
|
perfectly compatible with your system).</P
|
|
><P
|
|
>High-level drivers present to the rest of the kernel an interface
|
|
appropriate to a certain class of devices. The SCSI high-level driver
|
|
for tape devices, <B
|
|
CLASS="COMMAND"
|
|
>st</B
|
|
>, for example, has ioctls to
|
|
rewind. The high-level SCSI driver for CD-ROM drives,
|
|
<B
|
|
CLASS="COMMAND"
|
|
>sr</B
|
|
>, does not.</P
|
|
><P
|
|
>Note that you rarely need a high-level driver specific to a certain
|
|
brand of device. At this level, there is little room for one brand to
|
|
be distinguishable from another.</P
|
|
><P
|
|
>One SCSI high-level driver that deserves special mention is
|
|
<B
|
|
CLASS="COMMAND"
|
|
>sg</B
|
|
>. This driver, called the "SCSI generic" driver,
|
|
is a fairly thin layer that presents a rather raw representation of
|
|
the SCSI mid-level driver to the rest of the kernel. User space
|
|
programs that operate through the SCSI generic driver (because they
|
|
access device special files whose major number is the one registered
|
|
by <B
|
|
CLASS="COMMAND"
|
|
>sg</B
|
|
> (to wit, 21)) have a detailed understanding
|
|
of SCSI protocols, whereas user space programs that operate through
|
|
other SCSI high-level drivers typically don't even know what SCSI is.
|
|
<I
|
|
CLASS="CITETITLE"
|
|
>SCSI-Programming-HOWTO</I
|
|
> has complete
|
|
documentation of the SCSI generic driver.</P
|
|
><P
|
|
>The layering order of the SCSI modules belies the way the LKMs depend
|
|
upon each other and the order in which they must be loaded. You
|
|
always load the mid-level driver first and unload it last. The
|
|
low-level and high-level drivers can be loaded and unloaded in any
|
|
order after that, and they hook themselves into and establish
|
|
dependency on the mid-level driver at both ends. If you don't have a
|
|
complete set, you will get a "device not found" error when you try to
|
|
access a device.</P
|
|
><P
|
|
>Most SCSI low-level (adapter) drivers don't have LKM parameters; they
|
|
do generally autoprobe for card settings. If your card responds to
|
|
some unconventional port address you must bind the driver into the
|
|
base kernel and use kernel "command line" options. See
|
|
<I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>. Or you can twiddle The
|
|
Source and recompile.</P
|
|
><P
|
|
>Many SCSI low-level drivers have documentation in the <TT
|
|
CLASS="FILENAME"
|
|
>drivers/scsi</TT
|
|
> directory in the Linux
|
|
source tree, in files called <TT
|
|
CLASS="FILENAME"
|
|
>README.</TT
|
|
>*.</P
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1283"
|
|
></A
|
|
>15.3.1. scsi_mod: SCSI mid-level driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe scsi_mod</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1288"
|
|
></A
|
|
>15.3.2. sd_mod: SCSI high-level driver for disk devices</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe sd_mod</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1293"
|
|
></A
|
|
>15.3.3. st: SCSI high-level driver for tape devices</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe st</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters for the LKM, but if you bind this module
|
|
into the base kernel, you can pass some parameters via the Linux boot
|
|
parameters. See <I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1299"
|
|
></A
|
|
>15.3.4. sr_mod: SCSI high-level driver for CD-ROM drives</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe sr_mod</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1304"
|
|
></A
|
|
>15.3.5. sg: SCSI high-level driver for generic SCSI devices</H3
|
|
><P
|
|
>See the explanation of this special high-level driver above.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe sg</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1310"
|
|
></A
|
|
>15.3.6. wd7000: SCSI low-level driver for 7000FASST</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe wd7000</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters for the LKM, but if you bind this module
|
|
into the base kernel, you can pass some parameters via the Linux boot
|
|
parameters. See <I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
><P
|
|
>This driver atoprobes the card and requires installed BIOS.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1317"
|
|
></A
|
|
>15.3.7. aha152x: SCSI low-level driver for Adaptec AHA152X/2825</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe aha152x</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters for the LKM, but if you bind this module
|
|
into the base kernel, you can pass some parameters via the Linux boot
|
|
parameters. See <I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
><P
|
|
>This driver atoprobes the card and requires installed BIOS.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1324"
|
|
></A
|
|
>15.3.8. aha1542: SCSI low-level driver for Adaptec AHA1542</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe aha1542</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters for the LKM, but if you bind this module
|
|
into the base kernel, you can pass some parameters via the Linux boot
|
|
parameters. See <I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
><P
|
|
>This driver autoprobes the card at 0x330 and 0x334 only.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1331"
|
|
></A
|
|
>15.3.9. aha1740: SCSI low-level driver for Adaptec AHA1740 EISA</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe aha1740</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>This driver autoprobes the card.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1337"
|
|
></A
|
|
>15.3.10. aic7xxx: SCSI low-level driver for Adaptec AHA274X/284X/294X</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe aic7xxx</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters for the LKM, but if you bind this module
|
|
into the base kernel, you can pass some parameters via the Linux boot
|
|
parameters. See <I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
><P
|
|
>This driver autoprobes the card and BIOS must be enabled.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1344"
|
|
></A
|
|
>15.3.11. advansys: SCSI low-level driver for AdvanSys/Connect.com</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe advansys asc_iopflag=1 asc_ioport=0x110,0x330 asc_dbglvl=1</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Module Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>asc_iopflag</DT
|
|
><DD
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>1</DT
|
|
><DD
|
|
><P
|
|
>enable port scanning</P
|
|
></DD
|
|
><DT
|
|
>0</DT
|
|
><DD
|
|
><P
|
|
>disable port scanning</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DD
|
|
><DT
|
|
>asc_ioport</DT
|
|
><DD
|
|
><P
|
|
>I/O port addresses to scan for Advansys SCSI adapters</P
|
|
></DD
|
|
><DT
|
|
>asc_dbglvl</DT
|
|
><DD
|
|
><P
|
|
> debugging level:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>0</DT
|
|
><DD
|
|
><P
|
|
>Errors only</P
|
|
></DD
|
|
><DT
|
|
>1</DT
|
|
><DD
|
|
><P
|
|
>High level tracing</P
|
|
></DD
|
|
><DT
|
|
>2-N</DT
|
|
><DD
|
|
><P
|
|
>Verbose tracing</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
>
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>If you bind this driver into the base kernel, you can pass parameters
|
|
to it via the kernel boot parameters. See
|
|
<I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1385"
|
|
></A
|
|
>15.3.12. in2000: SCSI low-level driver for Always IN2000</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe in2000</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>This driver autoprobes the card. No BIOS is required.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1391"
|
|
></A
|
|
>15.3.13. BusLogic: SCSI low-level driver for BusLogic</H3
|
|
><P
|
|
>The list of BusLogic cards this driver can drive is long. Read file
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>drivers/scsi/README.BusLogic</TT
|
|
> in the Linux source
|
|
tree to get the total picture.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe BusLogic</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>If you bind this driver into the base kernel, you can pass parameters
|
|
to it via the kernel boot parameters. See
|
|
<I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1400"
|
|
></A
|
|
>15.3.14. dtc: SCSI low-level driver for DTC3180/3280</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe dtc</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters for the LKM, but if you bind this module
|
|
into the base kernel, you can pass some parameters via the Linux boot
|
|
parameters. See <I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
><P
|
|
>This driver autoprobes the card.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1407"
|
|
></A
|
|
>15.3.15. eata: SCSI low-level driver for EATA ISA/EISA</H3
|
|
><P
|
|
>This driver handles DPT PM2011/021/012/022/122/322.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe eata</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters for the LKM, but if you bind this module
|
|
into the base kernel, you can pass some parameters via the Linux boot
|
|
parameters. See <I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1414"
|
|
></A
|
|
>15.3.16. eata_dma: SCSI low-level driver for EATA-DMA</H3
|
|
><P
|
|
>This driver handles DPT, NEC, AT&T, SNI, AST, Olivetti, and Alphatronix.</P
|
|
><P
|
|
>This driver handles DPT Smartcache, Smartcache III and SmartRAID.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe eata_dma</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>Autoprobe works in all configurations.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1422"
|
|
></A
|
|
>15.3.17. eata_pio: SCSI low-level driver for EATA-PIO</H3
|
|
><P
|
|
>This driver handles old DPT PM2001, PM2012A.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> modprobe eata_pio</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1428"
|
|
></A
|
|
>15.3.18. fdomain: SCSI low-level driver for Future Domain 16xx</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe fdomain</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>This driver autoprobes the card and requires installed BIOS.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1434"
|
|
></A
|
|
>15.3.19. NCR5380: SCSI low-level driver for NCR5380/53c400</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe NCR5380 ncr_irq=xx ncr_addr=xx ncr_dma=xx ncr_5380=1 \
|
|
ncr_53c400=1</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
for a port mapped NCR5380 board:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe g_NCR5380 ncr_irq=5 ncr_addr=0x350 ncr_5380=1</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
for a memory mapped NCR53C400 board with interrupts disabled:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe g_NCR5380 ncr_irq=255 ncr_addr=0xc8000 ncr_53c400=1</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>ncr_irq</DT
|
|
><DD
|
|
><P
|
|
> the irq the driver is to service. 255 means no or DMA interrupt.
|
|
254 to autoprobe for an IRQ line if overridden on the command line.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>ncr_addr</DT
|
|
><DD
|
|
><P
|
|
> the I/O port address or memory mapped I/O address, whichever
|
|
is appropriate, that the driver is to drive
|
|
</P
|
|
></DD
|
|
><DT
|
|
>ncr_dma</DT
|
|
><DD
|
|
><P
|
|
> the DMA channel the driver is to use
|
|
</P
|
|
></DD
|
|
><DT
|
|
>ncr_5380</DT
|
|
><DD
|
|
><P
|
|
> 1 = set up for a NCR5380 board
|
|
</P
|
|
></DD
|
|
><DT
|
|
>ncr_53c400</DT
|
|
><DD
|
|
><P
|
|
> 1 = set up for a NCR53C400 board
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>If you bind this driver into the base kernel, you can pass parameters
|
|
to it via the kernel boot parameters. See
|
|
<I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1464"
|
|
></A
|
|
>15.3.20. NCR53c406a: SCSI low-level driver for NCR53c406a</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe NCR53c406a</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters for the LKM, but if you bind this module
|
|
into the base kernel, you can pass some parameters via the Linux boot
|
|
parameters. See <I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1470"
|
|
></A
|
|
>15.3.21. 53c7,8xx.o: SCSI low-level driver for NCR53c7,8xx</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe 53c7,8xx</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters for the LKM, but if you bind this module
|
|
into the base kernel, you can pass some parameters via the Linux boot
|
|
parameters. See <I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
><P
|
|
>This driver autoprobes the card and requires installed BIOS.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1477"
|
|
></A
|
|
>15.3.22. ncr53c8xx: SCSI low-level driver for PCI-SCS NCR538xx family</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe ncr53c8xx</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1482"
|
|
></A
|
|
>15.3.23. ppa: low-level SCSI driver for IOMEGA parallel port ZIP drive</H3
|
|
><P
|
|
>See the file <TT
|
|
CLASS="FILENAME"
|
|
>drivers/scsi/README.ppa</TT
|
|
> in the Linux
|
|
source tree for details.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe ppa ppa_base=0x378 ppa_nybble=1</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>ppa_base</DT
|
|
><DD
|
|
><P
|
|
> Base address of the PPA's I/O port. Default 0x378.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>ppa_speed_high</DT
|
|
><DD
|
|
><P
|
|
> Delay used in data transfers, in microseconds. Default is 1.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>ppa_speed_low</DT
|
|
><DD
|
|
><P
|
|
> Delay used in other operations, in microseconds. Default is 6.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>ppa_nybble</DT
|
|
><DD
|
|
><P
|
|
> 1 = Use 4-bit mode. 0 = don't. Default is 0.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1506"
|
|
></A
|
|
>15.3.24. pas16: SCSI low-level driver for PAS16</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe pas16</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters for the LKM, but if you bind this module
|
|
into the base kernel, you can pass some parameters via the Linux boot
|
|
parameters. See <I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
><P
|
|
>This driver autoprobes the card. No BIOS is required.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1513"
|
|
></A
|
|
>15.3.25. qlogicfas: SCSI low-level driver for Qlogic FAS</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe qlogicfas</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters for the LKM, but if you bind this module
|
|
into the base kernel, you can pass some parameters via the Linux boot
|
|
parameters. See <I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1519"
|
|
></A
|
|
>15.3.26. qlogicisp: SCSI low-level driver for Qlogic ISP</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe qlogicisp</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters for the LKM, but if you bind this module
|
|
into the base kernel, you can pass some parameters via the Linux boot
|
|
parameters. See <I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
><P
|
|
>Requires firmware.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1526"
|
|
></A
|
|
>15.3.27. seagate: SCSI low-level driver for Seagate, Future Domain</H3
|
|
><P
|
|
>This driver is for Seagate ST-02 and Future Domain TMC-8xx.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> modprobe seagate</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters for the LKM, but if you bind this module
|
|
into the base kernel, you can pass some parameters via the Linux boot
|
|
parameters. See <I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
><P
|
|
>This driver autoprobes for address only. The IRQ is fixed at 5.
|
|
The driver requires installed BIOS.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1534"
|
|
></A
|
|
>15.3.28. t128: SCSI low-level driver for Trantor T128/T128F/T228</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> modprobe t128</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters for the LKM, but if you bind this module
|
|
into the base kernel, you can pass some parameters via the Linux boot
|
|
parameters. See <I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
><P
|
|
>This driver autoprobes the card. The driver requires installed BIOS.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1541"
|
|
></A
|
|
>15.3.29. u14-34f: SCSI low-level driver for UltraStor 14F/34F</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> modprobe u14-34f</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters for the LKM, but if you bind this module
|
|
into the base kernel, you can pass some parameters via the Linux boot
|
|
parameters. See <I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
><P
|
|
>This driver autoprobes the card, but <EM
|
|
>not</EM
|
|
> the
|
|
0x310 port. No BIOS is required.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1549"
|
|
></A
|
|
>15.3.30. ultrastor: low-level SCSI driver for UltraStor</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe ultrastor</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters for the LKM, but if you bind this module
|
|
into the base kernel, you can pass some parameters via the Linux boot
|
|
parameters. See <I
|
|
CLASS="CITETITLE"
|
|
>BootPrompt-HOWTO</I
|
|
>.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN1555"
|
|
></A
|
|
>15.4. Network Device Drivers</H2
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1557"
|
|
></A
|
|
>15.4.1. bsd_comp: optional BSD compressor for PPP</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe bsd_comp</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>ppp</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1564"
|
|
></A
|
|
>15.4.2. slhc: SLHC compressor for PPP</H3
|
|
><P
|
|
>This module contains routines to compress and uncompress tcp packets
|
|
(for transmission over low speed serial lines). </P
|
|
><P
|
|
>These routines are required by PPP (also ISDN-PP) and SLIP protocols,
|
|
and are used by the LKMs that implement those protocols.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe slhc</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1571"
|
|
></A
|
|
>15.4.3. dummy: Dummy network interface driver</H3
|
|
><P
|
|
>This is said to be a bit-bucket device (i.e. traffic you send to this
|
|
device is consigned into oblivion) with a configurable IP address. It
|
|
is most commonly used in order to make your currently inactive SLIP
|
|
address seem like a real address for local programs.</P
|
|
><P
|
|
>However, it also functions as a sort of loopback device. You
|
|
configure it for a particular IP address and any packet you send to
|
|
that IP address via this interface comes back and appears as a packet
|
|
received by that interface for that IP address. This is especially
|
|
handy for an IP address that would normally be reflected by another
|
|
interface (a PPP interface, perhaps), but that interface is down right
|
|
now.</P
|
|
><P
|
|
>You can have multiple dummy interfaces. They are named
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>dummy0</TT
|
|
>, <TT
|
|
CLASS="LITERAL"
|
|
>dummy1</TT
|
|
>,
|
|
etc.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe dummy</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1581"
|
|
></A
|
|
>15.4.4. eql: serial line load balancer</H3
|
|
><P
|
|
>If you have two serial connections to some other computer (this
|
|
usually requires two modems and two telephone lines) and you use PPP
|
|
(a protocol for sending internet traffic over telephone lines) or SLIP
|
|
(an older alternative to PPP) on them, you can make them behave like
|
|
one double speed connection using this driver.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe eql</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1587"
|
|
></A
|
|
>15.4.5. dlci: frame relay DLCI driver</H3
|
|
><P
|
|
>This implements the frame relay protocol; frame relay is a fast
|
|
low-cost way to connect to a remote internet access provider or to
|
|
form a private wide area network. The one physical line from your box
|
|
to the local "switch" (i.e. the entry point to the frame relay
|
|
network) can carry several logical point-to-point connections to other
|
|
computers connected to the frame relay network. To use frame relay,
|
|
you need supporting hardware (FRAD) and certain programs from the net-
|
|
tools package as explained in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>Documentation/networking/framerelay.txt</TT
|
|
> in the
|
|
Linux source tree.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe dlci</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1594"
|
|
></A
|
|
>15.4.6. sdla: Sangoma S502A FRAD driver</H3
|
|
><P
|
|
>This is a driver for the Sangoma S502A, S502E and S508 Frame Relay
|
|
Access Devices. These are multi-protocol cards, but this driver can
|
|
drive only frame relay right now. Please read
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>Documentation/networking/framerelay.txt</TT
|
|
> in the
|
|
Linux source tree.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe sdla</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>dlci</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1603"
|
|
></A
|
|
>15.4.7. plip: PLIP network interface driver</H3
|
|
><P
|
|
>PLIP (Parallel Line Internet Protocol) is used to create a mini
|
|
network consisting of two (or, rarely, more) local machines. The
|
|
parallel ports (the connectors virtually all ISA-descendant computers
|
|
have that are normally used to attach printers) are connected using
|
|
"null printer" or "Turbo Laplink" cables which can transmit 4 bits at
|
|
a time or using special PLIP cables, to be used on bidirectional
|
|
parallel ports only, which can transmit 8 bits at a time. The cables
|
|
can be up to 15 meters long. This works also if one of the machines
|
|
runs DOS/Windows and has some PLIP software installed, e.g. the
|
|
Crynwr PLIP packet driver and <SPAN
|
|
CLASS="APPLICATION"
|
|
>winsock</SPAN
|
|
> or
|
|
NCSA's <B
|
|
CLASS="COMMAND"
|
|
>telnet</B
|
|
>.</P
|
|
><P
|
|
>See <I
|
|
CLASS="CITETITLE"
|
|
>PLIP-Install-HOWTO</I
|
|
>.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe plip io=0x378 irq=7</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Port address of parallel port driver is to drive.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ number of IRQ driver is to service. Default is IRQ 5 for
|
|
port at 0x3bc, IRQ 7 for port at 0x378, and IRQ 9 for port
|
|
at 0x278.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
>
|
|
|
|
If you don't specify the <TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>io</I
|
|
></TT
|
|
> parameter, the
|
|
driver probes addresses 0x278, 0x378, and 0x3bc.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1623"
|
|
></A
|
|
>15.4.8. ppp: PPP network protocol driver</H3
|
|
><P
|
|
>PPP (Point to Point Protocol) is the most common protocol to use over
|
|
a serial port (with or without a modem attached) to create an IP
|
|
network link between two computers.</P
|
|
><P
|
|
>Along with this kernel driver, you need the user space program
|
|
<B
|
|
CLASS="COMMAND"
|
|
>pppd</B
|
|
> running.</P
|
|
><P
|
|
>See <I
|
|
CLASS="CITETITLE"
|
|
>PPP-HOWTO</I
|
|
>.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe ppp</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>slhc</B
|
|
>.</P
|
|
><P
|
|
>The module also accesses serial devices, which are driven by the
|
|
<B
|
|
CLASS="COMMAND"
|
|
>serial</B
|
|
> module, so it depends on that module too.
|
|
This dependency is not detected by <B
|
|
CLASS="COMMAND"
|
|
>depmod</B
|
|
>, so you
|
|
either have to declare it manually or load <B
|
|
CLASS="COMMAND"
|
|
>serial</B
|
|
>
|
|
explicitly.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1639"
|
|
></A
|
|
>15.4.9. slip: SLIP network protocol driver</H3
|
|
><P
|
|
>SLIP (Serial Line Internet Protocol) is like PPP, only older and simpler.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe slip slip_maxdev=1</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>slip_maxdev</DT
|
|
><DD
|
|
><P
|
|
> Maximum number of devices the driver may use at one time. Default
|
|
is 256.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>slhc</B
|
|
>.</P
|
|
><P
|
|
>The module also accesses serial devices, which are driven by the
|
|
<B
|
|
CLASS="COMMAND"
|
|
>serial</B
|
|
> module, so it depends on that module too.
|
|
This dependency is not detected by <B
|
|
CLASS="COMMAND"
|
|
>depmod</B
|
|
>, so you
|
|
either have to declare it manually or load <B
|
|
CLASS="COMMAND"
|
|
>serial</B
|
|
>
|
|
explicitly.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1656"
|
|
></A
|
|
>15.4.10. baycom: BAYCOM AX.25 amateur radio driver</H3
|
|
><P
|
|
>This is a driver for Baycom style simple amateur radio modems that
|
|
connect to either a serial interface or a parallel interface. The
|
|
driver works with the ser12 and par96 designs. </P
|
|
><P
|
|
>For more information, see <A
|
|
HREF="http://www.baycom.org/~tom<"
|
|
TARGET="_top"
|
|
>http://www.baycom.org/~tom</A
|
|
>.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe baycom modem=1 iobase=0x3f8 irq=4 options=1</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>major</DT
|
|
><DD
|
|
><P
|
|
> major number the driver should use; default 60
|
|
</P
|
|
></DD
|
|
><DT
|
|
>modem</DT
|
|
><DD
|
|
><P
|
|
>
|
|
modem type of the first channel (minor 0):
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>1</DT
|
|
><DD
|
|
><P
|
|
>ser12</P
|
|
></DD
|
|
><DT
|
|
>2</DT
|
|
><DD
|
|
><P
|
|
>par96/par97</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
>
|
|
</P
|
|
></DD
|
|
><DT
|
|
>iobase</DT
|
|
><DD
|
|
><P
|
|
> base address of the port the driver is to drive. Common
|
|
values are for ser12 0x3f8, 0x2f8, 0x3e8, 0x2e8 and for
|
|
par96/par97 0x378, 0x278, 0x3bc.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service. Common values are 3 and 4 for ser12
|
|
and 7 for for par96/par97.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>options</DT
|
|
><DD
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>0</DT
|
|
><DD
|
|
><P
|
|
>use hardware DCD</P
|
|
></DD
|
|
><DT
|
|
>1</DT
|
|
><DD
|
|
><P
|
|
>use software DCD</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1702"
|
|
></A
|
|
>15.4.11. strip: STRIP (Metricom starmode radio IP) driver</H3
|
|
><P
|
|
>STRIP is a radio protocol developed for the <A
|
|
HREF="http://mosquitonet.stanford.edu/"
|
|
TARGET="_top"
|
|
>MosquitoNet project</A
|
|
> to
|
|
send Internet traffic using Metricom radios. Metricom radios are
|
|
small, battery powered, 100kbit/sec packet radio transceivers, about
|
|
the size and weight of a wireless telephone. (You may also have heard
|
|
them called "Metricom modems" but we avoid the term "modem" because it
|
|
misleads many people into thinking that you can plug a Metricom modem
|
|
into a phone line and use it as a modem.) You can use STRIP on any
|
|
Linux machine with a serial port, although it is obviously most useful
|
|
for people with laptop computers.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe strip</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1709"
|
|
></A
|
|
>15.4.12. wavelan: WaveLAN driver</H3
|
|
><P
|
|
>WaveLAN card are for wireless ethernet-like networking. This driver
|
|
drives AT&T GIS and NCR WaveLAN cards.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe wavelan io=0x390 irq=0</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card. Default is 0x390. You can set
|
|
a different address on the card, but it is not recommended.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service. Default is 0. Any other value
|
|
is ignored and the card still services IRQ 0.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1724"
|
|
></A
|
|
>15.4.13. wic: WIC Radio IP bridge driver</H3
|
|
><P
|
|
>This is a driver for the WIC parallel port radio bridge.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe wic</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>It appears that devices <TT
|
|
CLASS="LITERAL"
|
|
>wic0</TT
|
|
>,
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>wic1</TT
|
|
> and <TT
|
|
CLASS="LITERAL"
|
|
>wic2</TT
|
|
> are directly
|
|
related to corresponding <TT
|
|
CLASS="LITERAL"
|
|
>lp</TT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>N</TT
|
|
>
|
|
ports.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1735"
|
|
></A
|
|
>15.4.14. scc: Z8530 SCC kiss emulation driver</H3
|
|
><P
|
|
>These cards are used to connect your Linux box to an amateur radio in
|
|
order to communicate with other computers. If you want to use this,
|
|
read <TT
|
|
CLASS="FILENAME"
|
|
>Documentation/networking/z8530drv.txt</TT
|
|
> in the
|
|
Linux kernel source tree and <I
|
|
CLASS="CITETITLE"
|
|
>HAM-HOWTO</I
|
|
>.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe scc</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1743"
|
|
></A
|
|
>15.4.15. 8390: General NS8390 Ethernet driver core</H3
|
|
><P
|
|
>This is driver code for the 8390 Ethernet chip on which many Ethernet
|
|
adapters are based. This is not a complete interface driver; the
|
|
routines in this module are used by drivers for particular Ethernet
|
|
adapters, such as <B
|
|
CLASS="COMMAND"
|
|
>ne</B
|
|
> and <B
|
|
CLASS="COMMAND"
|
|
>3c503</B
|
|
>.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>
|
|
modprobe 8390</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1751"
|
|
></A
|
|
>15.4.16. ne: NE2000/NE1000 driver</H3
|
|
><P
|
|
>This is a driver for the venerable NE2000 Ethernet adapter, its
|
|
NE1000 forerunner, and all the generic Ethernet adapters that emulate
|
|
this de facto standard card.
|
|
|
|
This is an ISA bus card. For the PCI version, see the ne2k-pci module. </P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe ne io=0x300 irq=11</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card. This parameter is mandatory,
|
|
but you may specify 0x000 to have the driver autoprobe 0x300,
|
|
0x280, 0x320, 0x340, and 0x360.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service. If you don't specify this, the
|
|
driver determines it by autoIRQ probing.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>bad</DT
|
|
><DD
|
|
><P
|
|
> The value 0xBAD means to assume the card is poorly designed in
|
|
that it does not acknowledge a reset or does not have a valid
|
|
0x57,0x57 signature. If you have such a card and do not specify
|
|
this option, the driver will not recognize it.
|
|
</P
|
|
><P
|
|
> With any other value, the option has no effect.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>You can repeat the options to specify additional cards. The
|
|
<TT
|
|
CLASS="VARNAME"
|
|
>n</TT
|
|
>th occurence of an option applies to the
|
|
<TT
|
|
CLASS="VARNAME"
|
|
>n</TT
|
|
>th card.</P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>8390</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1776"
|
|
></A
|
|
>15.4.17. ne2k-pci: NE2000 PCI Driver</H3
|
|
><P
|
|
>This is a driver for the PCI version of the venerable NE2000 Ethernet
|
|
adapter, and all the generic Ethernet adapters that emulate this de
|
|
facto standard card.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe ne io=0x300 irq=11</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>debug</DT
|
|
><DD
|
|
><P
|
|
> Level of debug messages. 0 means no messages. 1 is the default.
|
|
Higher numbers mean more debugging messages.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>options</DT
|
|
><DD
|
|
><P
|
|
> The value of this option determines what options are set in the
|
|
network adapter. Each bit of the value, expressed as a binary
|
|
number, controls one option. The only option defined is full
|
|
duplex, which is the 6th least significant bit. It is much
|
|
easier to use the <TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>full_duplex</I
|
|
></TT
|
|
> option
|
|
instead.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>full_duplex</DT
|
|
><DD
|
|
><P
|
|
> A "1" value sets the adapter in full duplex mode.
|
|
A "0" value sets it in half duplex mode. If you include
|
|
the full duplex flag in the flags you specify with the
|
|
<TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>options</I
|
|
></TT
|
|
> parameter, the
|
|
<TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>full_duplex</I
|
|
></TT
|
|
> has no effect.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>You may repeat the <TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>options</I
|
|
></TT
|
|
> and
|
|
<TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>full_duplex</I
|
|
></TT
|
|
> parameters once per network
|
|
adapter, for up to 8 network adapter. </P
|
|
><P
|
|
>This driver can drive the following chipsets:
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>RealTek RTL-8029</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Winbond 89C940</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Winbond W89C940F</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>KTI ET32P2</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>NetVin NV5000SC</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Via 86C926</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>SureCom NE34</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Holtek HT80232</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Holtek HT80229</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Compex RL2000</P
|
|
></LI
|
|
></UL
|
|
></P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>8390</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1825"
|
|
></A
|
|
>15.4.18. 3c501: 3COM 3c501 Ethernet driver</H3
|
|
><P
|
|
>This is a driver for 3COM's 3c501 Ethernet adapter.</P
|
|
><P
|
|
>Example:
|
|
|
|
modprobe 3c501 io=0x280 irq=5 </P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service. Default is 5.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
>
|
|
If you don't specify an I/O port, the driver probes addresses 0x280
|
|
and 0x300.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1839"
|
|
></A
|
|
>15.4.19. 3c503: 3COM 3c503 driver</H3
|
|
><P
|
|
>This is a driver for 3COM's 3c503 Ethernet adapter.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe 3c503 io=0x300 irq=5 xcvr=0</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>xcvr</DT
|
|
><DD
|
|
><P
|
|
> Determines whether to use external tranceiver.
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>0</DT
|
|
><DD
|
|
><P
|
|
> no
|
|
</P
|
|
></DD
|
|
><DT
|
|
>1</DT
|
|
><DD
|
|
><P
|
|
> yes
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
>
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
>
|
|
If you don't specify an I/O port, the driver probes addresses 0x300,
|
|
0x310, 0x330, 0x350, 0x250, 0x280, 0x2A0, and 0x2E0. </P
|
|
><P
|
|
>
|
|
This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>8390</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1869"
|
|
></A
|
|
>15.4.20. 3c505: 3COM 3c505 driver</H3
|
|
><P
|
|
>This is a driver for 3COM's 3c505 Ethernet adapter.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe 3c503 io=0x300 irq=5 xcvr=0</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
>
|
|
|
|
If you don't specify an I/O port, the driver probes addresses 0x300,
|
|
0x280, and 0x310.</P
|
|
><P
|
|
>
|
|
This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>8390</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1886"
|
|
></A
|
|
>15.4.21. 3c507: 3COM 3c507 driver</H3
|
|
><P
|
|
>This is a driver for 3COM's 3c507 Ethernet adapter.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe 3c503 io=0x300 irq=5 xcvr=0</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
>
|
|
|
|
If you don't specify an I/O port, the driver probes addresses 0x300,
|
|
0x320, 0x340, and 0x280.</P
|
|
><P
|
|
>
|
|
This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>8390</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1903"
|
|
></A
|
|
>15.4.22. 3c509: 3COM 3c509/3c579 driver</H3
|
|
><P
|
|
>This is a driver for 3COM's 3c507 and 3c579 Ethernet adapters.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe 3c503 io=0x300 irq=5 xcvr=0</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>Module load-time probing Works reliably only on EISA, ISA ID-PROBE IS
|
|
NOT RELIABLE! Bind this driver into the base kernel for now, if you
|
|
need it auto-probing on an ISA-bus machine. </P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1919"
|
|
></A
|
|
>15.4.23. 3c59x: 3COM 3c590 series "Vortex" driver</H3
|
|
><P
|
|
>This is a driver for the following 3COM Ethernet adapters:
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>3c590 Vortex 10Mbps. </P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>3c595 Vortex 100baseTX. </P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>3c595 Vortex 100baseT4. </P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>3c595 Vortex 100base-MII. </P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>EISA Vortex 3c597. </P
|
|
></LI
|
|
></UL
|
|
></P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe 3c59x debug=1 options=0,,12</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>debug</DT
|
|
><DD
|
|
><P
|
|
> A number selecting the level of debug messages.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>options</DT
|
|
><DD
|
|
><P
|
|
> This is a string of options numbers separated by commas.
|
|
There is one option number for each adapter that the driver
|
|
drives (for the case that you have multiple Ethernet adapters
|
|
in the system of types driven by this driver). The order of
|
|
the option numbers is the order of the cards assigned by the
|
|
PCI BIOS.
|
|
</P
|
|
><P
|
|
> Each number represents a binary value. In that value, the
|
|
lower 3 bits is the media type:
|
|
</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>0</DT
|
|
><DD
|
|
><P
|
|
>10baseT</P
|
|
></DD
|
|
><DT
|
|
>1</DT
|
|
><DD
|
|
><P
|
|
>10Mbs AUI</P
|
|
></DD
|
|
><DT
|
|
>2</DT
|
|
><DD
|
|
><P
|
|
>undefined</P
|
|
></DD
|
|
><DT
|
|
>3</DT
|
|
><DD
|
|
><P
|
|
>10base2 (BNC)</P
|
|
></DD
|
|
><DT
|
|
>4</DT
|
|
><DD
|
|
><P
|
|
>100base-TX</P
|
|
></DD
|
|
><DT
|
|
>5</DT
|
|
><DD
|
|
><P
|
|
>100base-FX</P
|
|
></DD
|
|
><DT
|
|
>6</DT
|
|
><DD
|
|
><P
|
|
>MII (not yet available)</P
|
|
></DD
|
|
><DT
|
|
>7</DT
|
|
><DD
|
|
><P
|
|
>Use default setting</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><P
|
|
> The next bit (the "8" bit) is on for full duplex, off for half.
|
|
</P
|
|
><P
|
|
>
|
|
The next bit (the "16" bit) is on to enable bus-master, which is
|
|
for experimental use only.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>
|
|
Details of the device driver implementation are at the top of the
|
|
source file.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN1982"
|
|
></A
|
|
>15.4.24. wd: Western Digital/SMC WD80*3 driver</H3
|
|
><P
|
|
>This is a driver for the Western Digital WD80*3 Ethernet adapters.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe wd io=0x300 irq=5 mem=0x0D0000 mem_end=0x0D8000</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card. </P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service. </P
|
|
></DD
|
|
><DT
|
|
>mem</DT
|
|
><DD
|
|
><P
|
|
> Shared memory address</P
|
|
></DD
|
|
><DT
|
|
>mem_end</DT
|
|
><DD
|
|
><P
|
|
> End of shared memory (address of next byte after it).</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>If you don't specify an I/O port, the driver probes 0x300, 0x280, 0x380,
|
|
and 0x240.</P
|
|
><P
|
|
>If you don't specify an IRQ, the driver reads it from the adapter's EEPROM
|
|
and with ancient cards that don't have it, the driver uses autoIRQ.</P
|
|
><P
|
|
>The driver depends on module <B
|
|
CLASS="COMMAND"
|
|
>8390</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2009"
|
|
></A
|
|
>15.4.25. smc-ultra: SMC Ultra/EtherEZ driver</H3
|
|
><P
|
|
>This is a driver for the SMC Ultra/EtherEZ Ethernet adapters.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe smc-ultra io=0x200 irq=5</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card. If you don't specify this,
|
|
the adapter probes 0x200, 0x220, 0x240, 0x280, 0x300, 0x340,
|
|
and 0x380.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service. Default is the value read from the
|
|
adapter's EEPROM.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>This driver depends on module <B
|
|
CLASS="COMMAND"
|
|
>8390</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2026"
|
|
></A
|
|
>15.4.26. smc9194: SMC 9194 driver</H3
|
|
><P
|
|
>This is a driver for SMC's 9000 series of Ethernet cards.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe smc9194 io=0x200 irq=5 ifport=0</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card. If you don't specify this,
|
|
the adapter probes 0x200, 0x220, etc. up through 0x3E0.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>ifport</DT
|
|
><DD
|
|
><P
|
|
> Type of Ethernet.
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>0</DT
|
|
><DD
|
|
><P
|
|
>autodetect</P
|
|
></DD
|
|
><DT
|
|
>1</DT
|
|
><DD
|
|
><P
|
|
>TP</P
|
|
></DD
|
|
><DT
|
|
>2</DT
|
|
><DD
|
|
><P
|
|
>AUI (or 10base2)</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
>
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>The debug level is settable in the source code.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2059"
|
|
></A
|
|
>15.4.27. at1700: AT1700 driver</H3
|
|
><P
|
|
>This is a driver for the AT1700 Ethernet adapter.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe at1700 io=0x260 irq=5</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card. If you don't specify this,
|
|
the adapter probes 0x260, 0x280, 0x2A0, 0x240, 0x340, 0x320,
|
|
0x380, and 0x300.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2074"
|
|
></A
|
|
>15.4.28. e2100: Cabletron E21xx driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe e2100 io=0x300 irq=5 mem=0xd0000 xcvr=0</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card. If you don't specify this,
|
|
the adapter probes 0x300, 0x280, 0x380, and 0x220.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the card is to generate and the driver is to service. (The
|
|
driver sets this value in the card).
|
|
</P
|
|
></DD
|
|
><DT
|
|
>mem</DT
|
|
><DD
|
|
><P
|
|
> shared memory address. Default is 0xd0000.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>xcvr</DT
|
|
><DD
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>0</DT
|
|
><DD
|
|
><P
|
|
> Don't select external transceiver
|
|
</P
|
|
></DD
|
|
><DT
|
|
>1</DT
|
|
><DD
|
|
><P
|
|
> Select external transceiver
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>8390</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2106"
|
|
></A
|
|
>15.4.29. depca: DEPCA, DE10x, DE200, DE201, DE202, DE422 driver</H3
|
|
><P
|
|
>This is a driver for the DEPCA, DE10x, DE200, DE201, DE202, and DE422
|
|
Ethernet adapters.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe depca io=0x200 irq=7</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card. If you don't specify this,
|
|
the adapter probes 0x300, and 0x200 on an ISA machine or
|
|
0x0c00 on an EISA machine.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service. Default is 7.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2121"
|
|
></A
|
|
>15.4.30. ewrk3: EtherWORKS 3 (DE203, DE204, DE205) driver</H3
|
|
><P
|
|
>This is a driver for the EtherWORKS 3 (DE203, D3204, and DE205)
|
|
Ethernet adapters.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe ewrk3 io=0x300 irq=5</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card. Default is 0x300.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service. Default is 5.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><P
|
|
>On an EISA bus, this driver does EISA probing.</P
|
|
><P
|
|
>On an ISA bus, this driver does no autoprobing when loaded as an LKM.
|
|
However, if you bind it into the base kernel, it probes addresses
|
|
0x100, 0x120, etc. up through 0x3C0 except 0x1E0 and 0x320.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2137"
|
|
></A
|
|
>15.4.31. eexpress: EtherExpress 16 driver</H3
|
|
><P
|
|
>This is a driver for the EtherExpress 16 Ethernet adapter.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe eexpress io=0x300 irq=5</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card. If you don't specify this,
|
|
the adapter probes 0x300, 0x270, 0x320, and 0x340.
|
|
1</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service. The default is the value read
|
|
from the adapter's EEPROM.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2152"
|
|
></A
|
|
>15.4.32. eepro: EtherExpressPro driver</H3
|
|
><P
|
|
>This is a driver for the EtherExpressPro Ethernet adapter.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe eepro io=0x200 irq=5</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card. If you don't specify this,
|
|
the adapter probes 0x200, 0x240, 0x280, 0x2C0, 0x300, 0x320, 0x340,
|
|
and 0x360.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2167"
|
|
></A
|
|
>15.4.33. fmv18k: Fujitsu FMV-181/182/183/184 driver</H3
|
|
><P
|
|
>This is a driver for the Fujitsu FMV-181, FMV-182, FMV-183, FMV-183,
|
|
and FMV-184 Ethernet adapters.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe fmv18x io=0x220 irq=5</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card. If you don't specify this,
|
|
the adapter probes 0x220, 0x240, 0x260, 0x280, 0x2a0, 0x2c0,
|
|
0x300, and 0x340.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2182"
|
|
></A
|
|
>15.4.34. hp-plus: HP PCLAN+ (27247B and 27252A) driver</H3
|
|
><P
|
|
>This is a driver for HP's PCLAN+ (27247B and 27252A) Ethernet adapters.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe hp-plus io=0x200 irq=5</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card. If you don't specify this,
|
|
the adapter probes 0x200, 0x240, 0x280, 0x2C0, 0x300, 0x320, and
|
|
0x340.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service. The default is the value the driver
|
|
reads from the adapter's configuration register.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>8390</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2199"
|
|
></A
|
|
>15.4.35. hp: HP PCLAN (27245, 27xxx) driver</H3
|
|
><P
|
|
>This is a driver for HP's PCLAN (27245 and other 27xxx series) Ethernet
|
|
adapters.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe hp io=0x300 irq=5</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card. If you don't specify this,
|
|
the adapter probes 0x300, 0x320, 0x340, 0x280, 0x2C0, 0x200,
|
|
and 0x240.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service. If you don't specify this, the
|
|
driver determines it by autoIRQ probing.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>8390</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2216"
|
|
></A
|
|
>15.4.36. hp100: HP 10/100VG PCLAN (ISA, EISA, PCI) driver</H3
|
|
><P
|
|
>This is a driver for HP's 10/100VG PCLAN Ethernet adapters. It works with
|
|
the ISA, EISA, and PCI versions.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe hp100 hp100_port=0x100</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>hp100_port</DT
|
|
><DD
|
|
><P
|
|
> Base address of I/O ports on the card. If you don't specify this,
|
|
the driver autoprobes 0x100, 0x120, etc. up through 0x3E0 on an
|
|
ISA bus. It does EISA probing on an EISA bus.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2227"
|
|
></A
|
|
>15.4.37. eth16i: ICL EtherTeam 16i/32 driver</H3
|
|
><P
|
|
>This is a driver for ICL's EtherTeam 16i (eth16i) and 32i (eth32i)
|
|
Ethernet adapters.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe eth16i io=0x2a0 irq=5</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> Address of I/O port on the card. If you don't specify this,
|
|
the adapter probes the following adddresses. For the eth16i
|
|
adapter: 0x260, 0x280, 0x2A0, 0x340, 0x320, 0x380, and 0x300.
|
|
For the eth32i: 0x1000, 0x2000, 0x3000, 0x4000, 0x5000,
|
|
0x6000, 0x7000, 0x8000, 0x9000, 0xA000, 0xB000, 0xC000,
|
|
0xD000, 0xE000, and 0xF000.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service. If you don't specify this, the
|
|
driver determines it by autoIRQ probing.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2242"
|
|
></A
|
|
>15.4.38. ni52: NI5210 driver</H3
|
|
><P
|
|
>This is a driver for the NI5210 Ethernet adapter.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe ni52 io=0x360 irq=9 memstart=0xd0000 memend=0xd4000</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2247"
|
|
></A
|
|
>15.4.39. ac3200: Ansel Communications EISA 3200 driver</H3
|
|
><P
|
|
>This is a driver for the Ansel Communications EISA 3200 Ethernet
|
|
adapter.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe ac3200</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>8390</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2254"
|
|
></A
|
|
>15.4.40. apricot: Apricot Xen-II on board ethernet driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe apricot io=0x300 irq=10</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> address of base I/O port on card.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ that driver is to service.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2268"
|
|
></A
|
|
>15.4.41. de4x5: DE425, DE434, DE435, DE450, DE500 driver</H3
|
|
><P
|
|
>This is a driver for the DE425, DE434, DE435, DE450, and DE500
|
|
Ethernet adapters.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>
|
|
modprobe de4x5 io=0x000b irq=10 is_not_dec=0</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> address of base I/O port.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>is_not_dec</DT
|
|
><DD
|
|
><P
|
|
> For a non-DEC card using the DEC 21040, 21041, or 21140 chip,
|
|
set this to 1.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2287"
|
|
></A
|
|
>15.4.42. tulip: DECchip Tulip (dc21x4x) PCI driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe tulip</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Read <TT
|
|
CLASS="FILENAME"
|
|
>Documentation/networking/tulip.txt</TT
|
|
> in the Linux
|
|
source tree.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2293"
|
|
></A
|
|
>15.4.43. dgrs: Digi Intl RightSwitch SE-X driver</H3
|
|
><P
|
|
>This is a driver for the Digi International RightSwitch SE-X EISA and
|
|
PCI boards. These boards have a 4 (EISA) or 6 (PCI) port Ethernet
|
|
switch and a NIC combined into a single board.</P
|
|
><P
|
|
>There is a tool for setting up input and output packet filters on each
|
|
port, called <B
|
|
CLASS="COMMAND"
|
|
>dgrsfilt</B
|
|
>.</P
|
|
><P
|
|
>The management tool lets you watch the performance graphically, as
|
|
well as set the SNMP agent IP and IPX addresses, IEEE Spanning Tree,
|
|
and Aging time. These can also be set from the command line when the
|
|
driver is loaded.</P
|
|
><P
|
|
>There is also a companion management tool, called
|
|
<B
|
|
CLASS="COMMAND"
|
|
>xrightswitch</B
|
|
>.</P
|
|
><P
|
|
>Examples:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe dgrs debug=1 dma=0 spantree=0 hashexpire=300 ipaddr=199,86,8,221
|
|
modprobe ipxnet=111</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>debug</DT
|
|
><DD
|
|
><P
|
|
> Level of debugging messages to print
|
|
</P
|
|
></DD
|
|
><DT
|
|
>dma</DT
|
|
><DD
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>0</DT
|
|
><DD
|
|
><P
|
|
> Disable DMA on PCI card
|
|
</P
|
|
></DD
|
|
><DT
|
|
>1</DT
|
|
><DD
|
|
><P
|
|
> Enable DMA on PCI card
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DD
|
|
><DT
|
|
>spantree</DT
|
|
><DD
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>0</DT
|
|
><DD
|
|
><P
|
|
> Disable IEEE spanning tree
|
|
</P
|
|
></DD
|
|
><DT
|
|
>1</DT
|
|
><DD
|
|
><P
|
|
> Enable IEEE spanning tree
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DD
|
|
><DT
|
|
>hashexpire</DT
|
|
><DD
|
|
><P
|
|
> Change address aging time, in seconds. Defaults is 300.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>ipaddr</DT
|
|
><DD
|
|
><P
|
|
> SNMP agent IP address. Value is IP address in dotted decimal
|
|
notation, except with commas instead of periods.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>ipxnet</DT
|
|
><DD
|
|
><P
|
|
> SNMP agent IPX network number
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2345"
|
|
></A
|
|
>15.4.44. de600: D-Link DE600 pocket adapter driver</H3
|
|
><P
|
|
>This is a driver for the D-Link DE600 pocket Ethernet adapter.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe de600 de600_debug=0</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>de600_debug</DT
|
|
><DD
|
|
><P
|
|
> The driver expects the adapter to be at port 0x378 and
|
|
generate IRQ 7. This is the same as the DOS
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>lpt1</TT
|
|
> device. These are compile time
|
|
options.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2357"
|
|
></A
|
|
>15.4.45. de620: D-Link DE620 pocket adapter driver</H3
|
|
><P
|
|
>This is a driver for the D-Link DE620 pocket Ethernet adapter.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe de620 bnc=0 utp=0 io=0x378 irq=7</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>bnc</DT
|
|
><DD
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>1</DT
|
|
><DD
|
|
><P
|
|
> Network is 10Base2
|
|
</P
|
|
></DD
|
|
><DT
|
|
>0</DT
|
|
><DD
|
|
><P
|
|
> Network is not 10Base2
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DD
|
|
><DT
|
|
>utp</DT
|
|
><DD
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>1</DT
|
|
><DD
|
|
><P
|
|
> Network is 10BaseT
|
|
</P
|
|
></DD
|
|
><DT
|
|
>0</DT
|
|
><DD
|
|
><P
|
|
> Network is not 10BaseT
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DD
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> I/O port address of port driver is to drive. Default is 0x378.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ driver is to service. Default is 7.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>You can't specify both <TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>bnc=1</I
|
|
></TT
|
|
> and
|
|
<TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>utp=1</I
|
|
></TT
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2399"
|
|
></A
|
|
>15.4.46. ibmtr: Tropic chipset based token ring adapter driver</H3
|
|
><P
|
|
>Example:</P
|
|
><P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe ibmtr io=0xa20 irq=5</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> I/O port address of port driver is to drive. Default is 0xa20.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ driver is to service. By default, the driver determines the
|
|
IRQ by autoIRQ probing.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2414"
|
|
></A
|
|
>15.4.47. arcnet: ARCnet driver</H3
|
|
><P
|
|
>Read The Fine Information in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>Documentation/networking/arcnet.txt</TT
|
|
> in the Linux
|
|
source tree. Also Arcnet hardware information
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>arcnet-hardware.txt</TT
|
|
> is found in same place.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe arcnet io=0x300 irq=2 shmem=0xd0000 device=arc1</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> I/O port address of port driver is to drive. If you don't
|
|
specify this, the driver probes addresses 0x300, 0x2E0, 0x2F0,
|
|
0x2D0, 0x200, 0x210, 0x220, 0x230, 0x240, 0x250, 0x260, 0x270,
|
|
0x280, 0x290, 0x2A0, 0x2B0, 0x2C0, 0x310, 0x320, 0x330, 0x340,
|
|
0x350, 0x360, 0x370, 0x380, 0x390, 0x3A0, 0x3E0, and 0x3F0.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ driver is to service. By default, the driver determines the
|
|
IRQ by autoIRQ probing.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>device</DT
|
|
><DD
|
|
><P
|
|
> device name.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2435"
|
|
></A
|
|
>15.4.48. isdn: basic ISDN functions</H3
|
|
><P
|
|
>This module provides ISDN functions used by ISDN adapter drivers.</P
|
|
><P
|
|
>Setting up ISDN networking is a complicated task. Read documentation
|
|
found in <TT
|
|
CLASS="FILENAME"
|
|
>Documentation/isdn</TT
|
|
> in the Linux source
|
|
tree.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe isdn</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>slhc</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2445"
|
|
></A
|
|
>15.4.49. icn: ICN 2B and 4B driver</H3
|
|
><P
|
|
>This is a driver for the ICN 2B and ICN 4B ISDN adapters.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe icn portbase=0x320 membase=0xd0000 icn_id=idstring icn_id2=idstring2</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>portbase</DT
|
|
><DD
|
|
><P
|
|
> Address of the base I/O port on the adapter. Defaults is 0x320.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>membase</DT
|
|
><DD
|
|
><P
|
|
> Address of shared memory. Default is 0xd0000.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>icn_id</DT
|
|
><DD
|
|
><P
|
|
> idstring for the first adapter. Must start with a character!
|
|
This parameter is required.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>icn_id2</DT
|
|
><DD
|
|
><P
|
|
> idstring for the second adapter. Must start with a character!
|
|
This parameter is required with the double card.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>isdn</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2470"
|
|
></A
|
|
>15.4.50. pcbit: PCBIT-D driver</H3
|
|
><P
|
|
>This is a driver for the PCBIT-D ISDN adapter driver.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe pcbit mem=0xd0000 irq=5</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>mem</DT
|
|
><DD
|
|
><P
|
|
> Shared memory address. Default is 0xd0000
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ the driver is to service. Default is 5.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>This module depend on module <B
|
|
CLASS="COMMAND"
|
|
>isdn</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2487"
|
|
></A
|
|
>15.4.51. teles: Teles/NICCY1016PC/Creatix driver</H3
|
|
><P
|
|
>This is a driver for the Teles/NICCY1016PC/Creatix ISDN adapter.
|
|
It can drive up to 16 cards.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe teles io=0xd0000,15,0xd80,2 teles_id=idstring</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>io</DT
|
|
><DD
|
|
><P
|
|
> This is a whole collection of parameters in one. It's syntax is
|
|
|
|
<TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>io=</I
|
|
></TT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>card1options</TT
|
|
>
|
|
[<TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>,</I
|
|
></TT
|
|
><TT
|
|
CLASS="VARNAME"
|
|
>card2options</TT
|
|
>
|
|
<TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>,</I
|
|
></TT
|
|
>...]
|
|
|
|
where <TT
|
|
CLASS="VARNAME"
|
|
>card1options</TT
|
|
> is a set of options
|
|
for the first card, etc.
|
|
</P
|
|
><P
|
|
>
|
|
The syntax of <TT
|
|
CLASS="VARNAME"
|
|
>card1options</TT
|
|
>, etc. is
|
|
|
|
<TT
|
|
CLASS="VARNAME"
|
|
>sharedmem</TT
|
|
><TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>,</I
|
|
></TT
|
|
>
|
|
<TT
|
|
CLASS="VARNAME"
|
|
>irq</TT
|
|
><TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>,</I
|
|
></TT
|
|
>
|
|
<TT
|
|
CLASS="VARNAME"
|
|
>portbase</TT
|
|
><TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>,</I
|
|
></TT
|
|
>
|
|
<TT
|
|
CLASS="VARNAME"
|
|
>dprotocol</TT
|
|
>
|
|
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>sharedmem</DT
|
|
><DD
|
|
><P
|
|
> Address of shared memory. Default 0xd0000
|
|
</P
|
|
></DD
|
|
><DT
|
|
>irq</DT
|
|
><DD
|
|
><P
|
|
> IRQ driver is to service.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>portbase</DT
|
|
><DD
|
|
><P
|
|
> Address of base I/O port.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>dprotocol</DT
|
|
><DD
|
|
><P
|
|
> D-channel protocol of the card
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>1</DT
|
|
><DD
|
|
><P
|
|
>1TR6</P
|
|
></DD
|
|
><DT
|
|
>2</DT
|
|
><DD
|
|
><P
|
|
> EDSS1. This is the default.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
>
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
>
|
|
</P
|
|
></DD
|
|
><DT
|
|
>teles_id</DT
|
|
><DD
|
|
><P
|
|
> Driver ID for accessing with utilities and identification
|
|
when using a line monitor. Value must start with a
|
|
character! Default: none.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>The driver determines the type of card from the port, irq and shared
|
|
memory address:
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>port == 0, shared memory != 0 -> Teles S0-8
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>port != 0, shared memory != 0 -> Teles S0-16.0
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>port != 0, shared memory == 0 -> Teles S0-16.3
|
|
</P
|
|
></LI
|
|
></UL
|
|
></P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>isdn</B
|
|
>.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN2553"
|
|
></A
|
|
>15.5. CDROM Device Drivers</H2
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2555"
|
|
></A
|
|
>15.5.1. aztcd: Aztech/Orchid/Okano/Wearnes/TXC/CDROM driver</H3
|
|
><P
|
|
>This is a driver for the Aztech, Orchid, Okano, Wearnes, TXC, and
|
|
CDROM devices (which have special non-SCSI non-ATA interfaces).</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> modprobe aztcd aztcd=0x340</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>aztcd</DT
|
|
><DD
|
|
><P
|
|
> address of base I/O port
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>Read <TT
|
|
CLASS="FILENAME"
|
|
>Documentation/cdrom/aztcd</TT
|
|
> in the Linux
|
|
source tree for full information.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2568"
|
|
></A
|
|
>15.5.2. gscd: Goldstar R420 CDROM driver</H3
|
|
><P
|
|
>This is a driver for the Goldstar R420 CDROM drive, which does not use
|
|
either an ATA or SCSI interface.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe gscd gscd=0x340</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>gscd</DT
|
|
><DD
|
|
><P
|
|
> address of base I/O port. Default is 0x340, which will
|
|
work for most applications. You select the address of the
|
|
drive with the PN801-1 through PN801-4 jumpers on the
|
|
Goldstar Interface Card. Appropriate settings are: 0x300,
|
|
0x310, 0x320, 0x330, 0x340, 0x350, 0x360, 0x370, 0x380,
|
|
0x390, 0x3A0, 0x3B0, 0x3C0, 0x3D0, 0x3E0, and 0x3F0.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2579"
|
|
></A
|
|
>15.5.3. sbpcd: Sound Blaster CDROM driver</H3
|
|
><P
|
|
>This is a driver for the Matsushita, Panasonic, Creative, Longshine, and
|
|
TEAC CDROM drives that don't attach via ATA or SCSI.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe sbpcd sbpcd=0x340</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>sbpcd</DT
|
|
><DD
|
|
><P
|
|
> address of base I/O port
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>An additional parameter is an SBPRO setting, as described in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>Documentation/cdrom/sbpcd</TT
|
|
> in the Linux source tree.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2592"
|
|
></A
|
|
>15.5.4. mcd: Mitsumi CDROM driver</H3
|
|
><P
|
|
>This is a driver for Mitsumi CDROM drives that don't attach via ATA
|
|
or SCSI. It does not handle XA or multisession.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe mcd mcd=0x300,11,0x304,5</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>mcd</DT
|
|
><DD
|
|
><P
|
|
> This is a comma separated list of i/o base addresses and IRQs,
|
|
in pairs.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2603"
|
|
></A
|
|
>15.5.5. mcdx: Mitsumi XA/MultiSession driver</H3
|
|
><P
|
|
>This driver is like <B
|
|
CLASS="COMMAND"
|
|
>mcd</B
|
|
>, only it has XA and
|
|
multisession functions.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe mcdx mcdx=0x300,11,0x304,5</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2609"
|
|
></A
|
|
>15.5.6. optcd: Optics Storage DOLPHIN 8000AT CDROM driver</H3
|
|
><P
|
|
>This is the driver for the so-called "dolphin" CDROM drive form Optics
|
|
Storage, with the 34-pin Sony-compatible interface. For the
|
|
ATA-compatible Optics Storage 8001 drive, you will want the ATAPI
|
|
CDROM driver. The driver also seems to work with the Lasermate
|
|
CR328A.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe optcd optcd=0x340</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>optcd</DT
|
|
><DD
|
|
><P
|
|
> address of base I/O port
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2620"
|
|
></A
|
|
>15.5.7. cm206: Philips/LMS CM206 CDROM driver</H3
|
|
><P
|
|
>This is the driver for the Philips/LMS cm206 CDROM drive in
|
|
combination with the cm260 host adapter card.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe cm206 cm206=0x300,11</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>cm206</DT
|
|
><DD
|
|
><P
|
|
> The address of the base I/O port the driver is to drive and
|
|
the IRQ the driver is to service, separated by a comma. It doesn't
|
|
matter what order you put them in, and you may specify just one,
|
|
in which case the other defaults.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2631"
|
|
></A
|
|
>15.5.8. sjcd: Sanyo CDR-H94A CDROM driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe sjcd sjcd_base=0x340</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>sjcd_base</DT
|
|
><DD
|
|
><P
|
|
> address of the base I/O port the driver is to drive.
|
|
Default is 0x340.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>The driver uses no IRQ and no DMA channel. </P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2642"
|
|
></A
|
|
>15.5.9. isp16: ISP16/MAD16/Mozart soft configurable cdrom driver</H3
|
|
><P
|
|
>This is a driver for the ISP16 or MAD16 or Mozart soft configurable
|
|
cdrom interface.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe isp16 isp16_cdrom_base=0x340 isp16_cdrom_irq=3
|
|
isp16_cdrom_dma=0 isp16_cdrom_type=Sanyo</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>isp16_cdrom_base</DT
|
|
><DD
|
|
><P
|
|
> address of base I/O port the driver is to drive. Valid values
|
|
are 0x340, 0x320, 0x330, and 0x360.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>isp16_cdrom_irq</DT
|
|
><DD
|
|
><P
|
|
>
|
|
IRQ the driver is to service. Valid values are 0, 3, 5, 7, 9, 10,
|
|
and 11.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>isp16_cdrom_dma</DT
|
|
><DD
|
|
><P
|
|
> DMA channel the driver is to use with the device. Valid
|
|
values are 0, 3, 5, 6, and 7.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>isp16_cdrom_type</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Type of device being driven. Valid values are
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>noisp16</TT
|
|
>, <TT
|
|
CLASS="LITERAL"
|
|
>Sanyo</TT
|
|
>,
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>Panasonic</TT
|
|
>, <TT
|
|
CLASS="LITERAL"
|
|
>Sony</TT
|
|
> and
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>Mitsumi</TT
|
|
>. Note that these values are
|
|
case sensitive.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2670"
|
|
></A
|
|
>15.5.10. cdu31a: Sony CDU31A/CDU33A CDROM driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> modprobe cdu31a cdu31a_port=0x340 cdu31a_irq=5</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>cdu31a_port</DT
|
|
><DD
|
|
><P
|
|
> address of base I/O port the driver is to drive. This parameter
|
|
is mandatory.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>cdu31a_irq</DT
|
|
><DD
|
|
><P
|
|
>
|
|
IRQ the driver is to service. If you don't specify this,
|
|
the driver does not use interrupts.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2684"
|
|
></A
|
|
>15.5.11. sonycd535: Sony CDU535 CDROM driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe sonycd535 sonycd535=0x340</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Parameters:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>sonycd535</DT
|
|
><DD
|
|
><P
|
|
> address of the base I/O port the driver is to drive.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN2694"
|
|
></A
|
|
>15.6. Filesystem Drivers</H2
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2696"
|
|
></A
|
|
>15.6.1. minix: Minix filesystem driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe minix</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2701"
|
|
></A
|
|
>15.6.2. ext: "Extended" filesystem driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe ext</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2706"
|
|
></A
|
|
>15.6.3. ext2: "Second extended" filessystem driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe ext2</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2711"
|
|
></A
|
|
>15.6.4. xiafs: xiafs filesystem driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe xiafs</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2716"
|
|
></A
|
|
>15.6.5. fat: DOS FAT filesystem functions</H3
|
|
><P
|
|
>This module provides services for use by the MSDOS and VFAT
|
|
filesystem drivers.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe fat</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2722"
|
|
></A
|
|
>15.6.6. msdos: MSDOS filesystem driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe msdos</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>This module depends on the module <B
|
|
CLASS="COMMAND"
|
|
>fat</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2729"
|
|
></A
|
|
>15.6.7. vfat: VFAT (Windows-95) filesystem driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe vfat</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>fat</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2736"
|
|
></A
|
|
>15.6.8. umsdos: UMSDOS filesystem driver</H3
|
|
><P
|
|
>This is a driver for the UMSDOS filesystem type, which is a unix style
|
|
filesystem built on top of an MSDOS FAT filesystem.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe vfat</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>This module depends on the <B
|
|
CLASS="COMMAND"
|
|
>fat</B
|
|
> and
|
|
<B
|
|
CLASS="COMMAND"
|
|
>msdos</B
|
|
> modules.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2745"
|
|
></A
|
|
>15.6.9. nfs: NFS filesystem driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe nfs</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2750"
|
|
></A
|
|
>15.6.10. smbfs: SMB filesystem driver</H3
|
|
><P
|
|
>SMBFS is a filesystem type which has an SMB protocol interface. This
|
|
is the protocol Windows for Workgroups, Windows NT or Lan Manager use
|
|
to talk to each other. SMBFS was inspired by Samba, the program
|
|
written by Andrew Tridgell that turns any unix host into a file server
|
|
for DOS or Windows clients. See <A
|
|
HREF="ftp://nimbus.anu.edu.au/pub/tridge/samba/"
|
|
TARGET="_top"
|
|
>ftp://nimbus.anu.edu.au/pub/tridge/samba/</A
|
|
> for this interesting
|
|
program suite and lots of more information on SMB and NetBIOS over
|
|
TCP/IP. There you also find explanation for concepts like netbios name
|
|
or share.</P
|
|
><P
|
|
>To use SMBFS, you need a special mount program, which can be found
|
|
in the ksmbfs package, found on
|
|
<A
|
|
HREF="ftp://ibiblio.org/pub/Linux/system/Filesystems/smbfs"
|
|
TARGET="_top"
|
|
>ftp://ibiblio.org/pub/Linux/system/Filesystems/smbfs</A
|
|
>.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe smbfs</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2759"
|
|
></A
|
|
>15.6.11. ncpfs: NCP (Netware) filesystem driver</H3
|
|
><P
|
|
>NCPFS is a filesystem type which has an NCP protocol interface,
|
|
designed by the Novell Corporation for their NetWare product. NCP is
|
|
functionally similar to the NFS used in the TCP/IP community. To
|
|
mount a Netware filesystem, you need a special mount program, which
|
|
can be found in the <SPAN
|
|
CLASS="APPLICATION"
|
|
>ncpfs</SPAN
|
|
> package.
|
|
Homesite for <SPAN
|
|
CLASS="APPLICATION"
|
|
>ncpfs</SPAN
|
|
> is
|
|
<A
|
|
HREF="ftp.gwdg.de/pub/linux/misc/ncpfs"
|
|
TARGET="_top"
|
|
>ftp.gwdg.de/pub/linux/misc/ncpfs</A
|
|
>, but Ibiblio and its many
|
|
mirrors will have it as well.</P
|
|
><P
|
|
>Related products are <SPAN
|
|
CLASS="APPLICATION"
|
|
>Linware</SPAN
|
|
> and
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>Mars_nwe</SPAN
|
|
>, which will give Linux partial
|
|
NetWare Server functionality.</P
|
|
><P
|
|
><SPAN
|
|
CLASS="APPLICATION"
|
|
>Mars_nwe</SPAN
|
|
> can be found on <A
|
|
HREF="ftp.gwdg.de/pub/linux/misc/ncpfs"
|
|
TARGET="_top"
|
|
>ftp.gwdg.de/pub/linux/misc/ncpfs</A
|
|
>.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe ncpfs</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>ipx</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2776"
|
|
></A
|
|
>15.6.12. isofs: ISO 9660 (CDROM) filesystem driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe isofs</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2781"
|
|
></A
|
|
>15.6.13. hpfs: OS/2 HPFS filesystem driver</H3
|
|
><P
|
|
>This filesystem driver for OS/2's HPFS filesystem provides only read-only
|
|
access.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe hpfs</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2787"
|
|
></A
|
|
>15.6.14. sysv: System V and Coherent filesystem driver</H3
|
|
><P
|
|
>This is the implementation of the SystemV/Coherent filesystem type for
|
|
Linux.</P
|
|
><P
|
|
>It implements all of
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>Xenix FS</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>SystemV/386 FS</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Coherent FS</P
|
|
></LI
|
|
></UL
|
|
></P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe sysv</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2801"
|
|
></A
|
|
>15.6.15. affs: Amiga FFS filesystem driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe affs</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2806"
|
|
></A
|
|
>15.6.16. ufs: UFS filesystem driver</H3
|
|
><P
|
|
>Apparently for mounting disks with FreeBSD and/or Sun partitions. No
|
|
documentation exists, apart from The Source.</P
|
|
><P
|
|
>This filesystem driver provides only read-only access.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe ufs</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN2813"
|
|
></A
|
|
>15.7. Miscellaneous Device Driver</H2
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2815"
|
|
></A
|
|
>15.7.1. misc: device driver for "miscellaneous" character devices</H3
|
|
><P
|
|
>A whole bunch of device types that don't appear in large enough numbers on
|
|
a system to deserve major numbers of their own share Major Number 10 and
|
|
are collectively called "miscellaneous" character devices. This module
|
|
provides the common interface to serve that major number, but there are
|
|
individual drivers for the specific device types. Those drivers register
|
|
themselves with this driver.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe misc</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN2821"
|
|
></A
|
|
>15.8. Serial Device Drivers</H2
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2823"
|
|
></A
|
|
>15.8.1. serial: serial communication port (UART) device driver</H3
|
|
><P
|
|
>This driver drives conventional serial ports (UARTs), but not some
|
|
of the specialized high performance multi-port devices.</P
|
|
><P
|
|
>NOTE: <B
|
|
CLASS="COMMAND"
|
|
>serial</B
|
|
> is required by other modules, such as
|
|
<B
|
|
CLASS="COMMAND"
|
|
>ppp</B
|
|
> and <B
|
|
CLASS="COMMAND"
|
|
>slip</B
|
|
>. Also it is
|
|
required by serial mice and accordingly by
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>gpm</SPAN
|
|
>. However this isn't the regular kind
|
|
of dependency that is detected by module handling tools, so you must
|
|
load <B
|
|
CLASS="COMMAND"
|
|
>serial</B
|
|
> manually.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe serial</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2835"
|
|
></A
|
|
>15.8.2. cyclades: Cyclades async mux device driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> modprobe cyclades</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>The intelligent boards also need to have their firmware code
|
|
downloaded to them. This is done via a user level application supplied
|
|
in the driver package called
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>stlload</SPAN
|
|
>. Compile this program where ever
|
|
you dropped the package files, by typing <B
|
|
CLASS="COMMAND"
|
|
>make</B
|
|
>. In
|
|
its simplest form you can then type <B
|
|
CLASS="COMMAND"
|
|
>stlload</B
|
|
> in this
|
|
directory and that will download firmware into board 0 (assuming board
|
|
0 is an EasyConnection 8/64 board). To download to an ONboard, Brumby
|
|
or Stallion do:</P
|
|
><P
|
|
>Read the information in the file
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>Documentation/stallion.txt</TT
|
|
> in the Linux source
|
|
tree.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2846"
|
|
></A
|
|
>15.8.3. stallion: Stallion EasyIO or EC8/32 device driver</H3
|
|
><P
|
|
>The intelligent boards also need to have their firmware code
|
|
downloaded to them. This is done via a user level application supplied
|
|
in the driver package called <SPAN
|
|
CLASS="APPLICATION"
|
|
>stlload</SPAN
|
|
>.</P
|
|
><P
|
|
>Read the information in the file
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>Documentation/stallion.txt</TT
|
|
> in the Linux source
|
|
tree.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> modprobe stallion</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2855"
|
|
></A
|
|
>15.8.4. istallion: Stallion EC8/64, ONboard, Brumby device driver</H3
|
|
><P
|
|
>The intelligent boards also need to have their firmware code
|
|
downloaded to them. This is done via a user level application supplied
|
|
in the driver package called <SPAN
|
|
CLASS="APPLICATION"
|
|
>stlload</SPAN
|
|
>.</P
|
|
><P
|
|
>Read the information at /usr/src/linux/drivers/char/README.stallion.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe istallion</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2863"
|
|
></A
|
|
>15.8.5. riscom8: SDL RISCom/8 card device driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe riscom8 iobase=0xXXX iobase1=0xXXX iobase2=...</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>This driver can drive up to 4 boards at time.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN2868"
|
|
></A
|
|
>15.9. Parallel Device Drivers</H2
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2870"
|
|
></A
|
|
>15.9.1. lp: Parallel printer device driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> modprobe lp.o io=0x378 irq=0</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>This driver probes ports 0x278, 0x378, and 0x3bc.</P
|
|
><P
|
|
>Note: loading <B
|
|
CLASS="COMMAND"
|
|
>lp</B
|
|
> without any parameters will
|
|
grab all parallel ports.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN2877"
|
|
></A
|
|
>15.10. Bus Mouse Device Drivers</H2
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2879"
|
|
></A
|
|
>15.10.1. atixlmouse: ATIXL busmouse driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe atixlmouse</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no parameters.</P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>misc</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2886"
|
|
></A
|
|
>15.10.2. busmouse: Logitech busmouse driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe busmouse</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>misc</B
|
|
>.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2893"
|
|
></A
|
|
>15.10.3. msbusmouse: Microsoft busmouse driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe msbusmouse</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>misc</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2900"
|
|
></A
|
|
>15.10.4. psaux: PS/2 mouse (aka "auxiliary device") driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe psaux</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>misc</B
|
|
>.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN2907"
|
|
></A
|
|
>15.11. Tape Device Drivers</H2
|
|
><P
|
|
>For SCSI tape device drivers, see <A
|
|
HREF="#SCSI"
|
|
>Section 15.3</A
|
|
>. There are no
|
|
LKMs for QIC-02 tape devices, but there is a device driver you can
|
|
bind into the base kernel.</P
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2911"
|
|
></A
|
|
>15.11.1. ftape: floppy tape (QIC-80/Travan) device driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe ftape tracing=3</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Optional parameter <TT
|
|
CLASS="PARAMETER"
|
|
><I
|
|
>tracing</I
|
|
></TT
|
|
> can take following
|
|
values
|
|
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>0</DT
|
|
><DD
|
|
><P
|
|
>bugs</P
|
|
></DD
|
|
><DT
|
|
>1</DT
|
|
><DD
|
|
><P
|
|
>+ errors</P
|
|
></DD
|
|
><DT
|
|
>2</DT
|
|
><DD
|
|
><P
|
|
>+ warnings</P
|
|
></DD
|
|
><DT
|
|
>3</DT
|
|
><DD
|
|
><P
|
|
>+ information</P
|
|
></DD
|
|
><DT
|
|
>4</DT
|
|
><DD
|
|
><P
|
|
>+ more information</P
|
|
></DD
|
|
><DT
|
|
>5</DT
|
|
><DD
|
|
><P
|
|
>+ program flow</P
|
|
></DD
|
|
><DT
|
|
>6</DT
|
|
><DD
|
|
><P
|
|
>+ fdc/dma info</P
|
|
></DD
|
|
><DT
|
|
>7</DT
|
|
><DD
|
|
><P
|
|
>+ data flow</P
|
|
></DD
|
|
><DT
|
|
>8</DT
|
|
><DD
|
|
><P
|
|
>+ everything else</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
><P
|
|
>The default is 3.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN2955"
|
|
></A
|
|
>15.12. Watchdog Timers</H2
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2957"
|
|
></A
|
|
>15.12.1. WDT: WDT Watchdog timer device driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe wdt</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>The device address is hardcoded as 0x240. The IRQ is hardcoded as 14.</P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>misc</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2965"
|
|
></A
|
|
>15.12.2. softdog: Software Watchdog Timer</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> modprobe softdog</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>misc</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><HR><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN2972"
|
|
></A
|
|
>15.12.3. pcwd: Berkshire Products PC Watchdog Driver</H3
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe pcwd</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>There are no module parameters.</P
|
|
><P
|
|
>This module depends on module <B
|
|
CLASS="COMMAND"
|
|
>misc</B
|
|
>.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><HR><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN2979"
|
|
></A
|
|
>15.13. Sound Device Drivers</H2
|
|
><P
|
|
>Configuring sound is a complex task. Read the files in
|
|
directory <TT
|
|
CLASS="FILENAME"
|
|
>Documention/sound</TT
|
|
> in
|
|
the Linux source tree.</P
|
|
><P
|
|
>Example:
|
|
<TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>modprobe sound</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Option: dma_buffsize=32768</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><HR><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN2986"
|
|
></A
|
|
>16. Maintenance Of This Document</H1
|
|
><P
|
|
>This HOWTO is enthusiastically maintained by Bryan Henderson
|
|
<TT
|
|
CLASS="EMAIL"
|
|
><<A
|
|
HREF="mailto:bryanh@giraffe-data.com"
|
|
>bryanh@giraffe-data.com</A
|
|
>></TT
|
|
>. If you find something
|
|
incorrect or incomplete or can't understand something, Bryan wants to
|
|
know so maybe the next reader can be saved the trouble you had.</P
|
|
><P
|
|
>The source for this document is DocBook SGML, and is available from
|
|
the <A
|
|
HREF="http://www.tldp.org"
|
|
TARGET="_top"
|
|
>Linux Documentation
|
|
Project</A
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><HR><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="HISTORY"
|
|
></A
|
|
>17. History</H1
|
|
><P
|
|
>I have derived this (in 2001) from the HOWTO of the same name by
|
|
Laurie Tischler, dated 1997. While I have kept all of the information
|
|
from that original document (where it is still useful), I have
|
|
rewritten the presentation entirely and have added a lot of other
|
|
information. The original HOWTO's primary purpose was to document
|
|
LKM parameters.</P
|
|
><P
|
|
>The original HOWTO was first released (Release 1.0) June 20, 1996,
|
|
with a second release (1.1) October 20, 1996.</P
|
|
><P
|
|
>The first release of Bryan's rewrite was in June 2001.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><HR><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN2997"
|
|
></A
|
|
>18. Copyright</H1
|
|
><P
|
|
>Here is Lauri Tischler's copyright notice from the original document
|
|
from which this is derived:</P
|
|
><P
|
|
>This document is Copyright <SPAN
|
|
CLASS="TRADEMARK"
|
|
>1996</SPAN
|
|
>© by Lauri Tischler. Permisson is
|
|
granted to make and distribute verbatim copies of this manual provided
|
|
the copyright notice and this permission notice are preserved on all
|
|
copies.</P
|
|
><P
|
|
>Permission is granted to copy and distribute modified versions of this
|
|
document under the conditions for verbatim copying, provided that this
|
|
copyright notice is included exactly as in the original, and that the
|
|
entire resulting derived work is distributed under the terms of a
|
|
permission notice identical to this one.</P
|
|
><P
|
|
>Permission is granted to copy and distribute translations of this
|
|
document into another language, under the above conditions for
|
|
modified versions.</P
|
|
><P
|
|
>Bryan Henderson, the current maintainer and contributing author of
|
|
this document, licenses it under the same terms as above. His work is
|
|
Copyright <SPAN
|
|
CLASS="TRADEMARK"
|
|
>2001</SPAN
|
|
>©.</P
|
|
></DIV
|
|
></DIV
|
|
><H3
|
|
CLASS="FOOTNOTES"
|
|
>Notes</H3
|
|
><TABLE
|
|
BORDER="0"
|
|
CLASS="FOOTNOTES"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="5%"
|
|
><A
|
|
NAME="FTN.AEN102"
|
|
HREF="#AEN102"
|
|
><SPAN
|
|
CLASS="footnote"
|
|
>[1]</SPAN
|
|
></A
|
|
></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="95%"
|
|
><P
|
|
>For the pedantic, see <A
|
|
HREF="#MEMALLOC"
|
|
>Section 10.7</A
|
|
>.</P
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="5%"
|
|
><A
|
|
NAME="FTN.AEN592"
|
|
HREF="#AEN592"
|
|
><SPAN
|
|
CLASS="footnote"
|
|
>[2]</SPAN
|
|
></A
|
|
></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="95%"
|
|
><P
|
|
>You probably know this type of disk as
|
|
"IDE". Strictly speaking, IDE is an incorrect appelation.
|
|
IDE refers to the "Integrated Drive Electronics" technology which all
|
|
modern disk drives, notably including all SCSI disk drives, use. The first IDE
|
|
drives in common usage were ATA, and the names kind of got confused.
|
|
ATA, like SCSI, is a precise specification of electrical signals,
|
|
commands, etc. </P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></BODY
|
|
></HTML
|
|
> |