Библиотека сайта rus-linux.net
|Purchase||Copyright © 2002 Paul Sheer. Click here for copying permissions.||Home|
Next: 43. The X Window Up: rute Previous: 41. Point-to-Point Protocol   Contents
- 42.1 Kernel Constitution
- 42.2 Kernel Version Numbers
- 42.3 Modules,
insmodCommand, and Siblings
- 42.4 Interrupts, I/O Ports, and DMA Channels
- 42.5 Module Options and Device Configuration
- 42.6 Configuring Various Devices
- 42.6.1 Sound and
- 42.6.2 Parallel port
- 42.6.3 NIC -- Ethernet, PCI, and old ISA
- 42.6.4 PCI vendor ID and device ID
- 42.6.5 PCI and sound
- 42.6.6 Commercial sound drivers
- 42.6.7 The ALSA sound project
- 42.6.8 Multiple Ethernet cards
- 42.6.9 SCSI disks
- 42.6.10 SCSI termination and cooling
- 42.6.11 CD writers
- 42.6.12 Serial devices
- 42.6.1 Sound and
- 42.7 Modem Cards
- 42.8 More on
- 42.9 Building the Kernel
- 42.10 Using Packaged Kernel Source
- 42.11 Building, Installing
This chapter explains how to configure, patch, and build a kernel from source. The configuration of device drivers and modules is also discussed in detail.
A kernel installation consists
of the kernel boot image, the kernel
System.map file, the kernel headers (needed
only for development), and various support daemons (already
provided by your distribution). These constitute everything that is
called ``Linux'' under LINUX, and are built from about 50 megabytes
of C code of around 1.5 million lines.
- The LINUX kernel image is a 400 to 600-KB file that sits in
/boot/(see Chapter 31). If you look in this directory, you might see several kernels. The choice of which to boot is probably available to you at boot time, through
The kernel in
/boot/is compressed. That is, it is
gzipcompressed and is actually about twice the size when unpacked into memory on boot.
- The kernel also has detached parts called modules.
These all sit in
/lib/modules/<version>/. They are categorized into the subdirectories below this directory. In kernel
2.2there were about 400, modules totaling about 9 megabytes.
Modules are actually just shared object files, like the
.ofiles we created in Section 23.1. They are not quite the same as Windows device drivers, in that it is not generally possibly to use a module on a kernel other than the one it was compiled for--hence the name ``module'' is used instead of ``driver.'' Modules are separated out of the kernel image purely to save RAM. Modules are sometimes compiled into the kernel in the same way that our
testprogram was statically linked on page . In this case, they would be absent from
/lib/modules/<version>/and should not really be called modules. In this chapter I show how to create compiled-in or compiled-out versions of modules when rebuilding the kernel.
- Next is the
System.mapfile, also in
/boot. It is used by
klogdto resolve kernel address references to symbols, so as to write logs about them, and then also by
depmodto work out module dependencies (what modules need what other modules to be loaded first).
- Finally, the kernel headers
/usr/src/linux/includeare used when certain packages are built.
- The ``various support daemons'' should be running
2.2, these have been reduced to
klogdonly. The other kernel daemons that appear to be running are generated by the kernel itself.
The kernel is versioned like other packages:
Development kernels are given odd minor version numbers; stable
kernels are given even minor version numbers. At the time of writing, the
stable kernel was
2.4.0 was soon to be released.
By the time you read this,
will be available. This chapter should
be entirely applicable to future stable releases of
A module is usually a device driver pertaining to some device node
generated with the
mknod command or already existing in the
/dev/ directory. For instance, the SCSI driver automatically locks onto
device major =
8, minor =
1,..., when it loads;
and the Sound module onto device major =
14, minor =
/dev/dsp), and others. The modules people most often play with are
SCSI, Ethernet, and Sound modules. There
are also many modules that support extra features instead of hardware.
Modules are loaded with the
insmod command, and removed with the
rmmod command. This is somewhat like the operation of linking
shown in the
Makefile on page . To list
currently loaded modules, use
lsmod. Try (kernel
2.4 paths are
different and are given in braces)
rmmod -a further removes all unused modules.
Modules sometimes need other modules to be present in order to
load. If you try to load a module and it gives
unresolved symbol <symbol-name> error messages, then it requires
something else to be loaded first. The
modprobe command loads
a module along with other modules that it depends on. Try
modprobe, however, requires a table of module dependencies.
This table is the
/lib/modules/<version>/modules.dep and is
generated automatically by your startup scripts with the command
although you can run it manually at any time. The
listing also shows module dependencies in brackets.
A loaded module that drives hardware will often consume I/O ports,
IRQs, and possibly a DMA channel, as explained in Chapter
3. You can get a full list of occupied
resources from the
The above configuration is typical. Note that the second column of the IRQ listing shows the number of interrupts signals received from the device. Moving my mouse a little and listing the IRQs again gives me
showing that several hundred interrupts were since
received. Another useful entry is
shows what major devices numbers were allocated and are being used.
This file is extremely useful for seeing what peripherals are
``alive'' on your system.
Device modules often need information about their hardware configuration. For instance, ISA device drivers need to know the IRQ and I/O port that the ISA card is physically configured to access. This information is passed to the module as module options that the module uses to initialize itself. Note that most devices will not need options at all. PCI cards mostly autodetect; it is mostly ISA cards that require these options.
- If a module is compiled into the kernel, then the module
will be initialized at boot time.
lilopasses module options to the kernel from the command-line at the
LILO:prompt. For instance, at the
LILO:prompt, you can type [See Section 4.4]:
- to initialize the
Adaptec 1542 SCSI driver. What these options are and exactly
what goes in them can be learned from the file
/usr/src/linux-<version>/drivers/scsi/aha1542.c. Near the top of the file are comments explaining the meaning of these options.
- If you are using
LOADLIN.EXEor some other DOS or Windows kernel loader, then it, too, can take similar options. I will not go into these.
/etc/lilo.confcan take the
append =option, as discussed on page . This options passes options to the kernel as though you had typed them at the
LILO:prompt. The equivalent
- This is the most common way of giving kernel boot options.
modprobecommands can take options that are passed to the module. These are vastly different from the way you pass options with
append =. For instance, you can give options to a compiled-in Ethernet module with the commands
- from within
/etc/lilo.conf. But then, using
modprobeon the same ``compiled-out'' modules, these options have to be specified like this:
- Note that the
0xd0000,0xd4000are only applicable to a few Ethernet modules and are usually omitted. Also, the
ether=0,0,eth1mean to try autodetect. To find out what options a module will take, you can use the
modinfocommand which shows that the
wddriver is one of the few Ethernet drivers where you can set their RAM usage. [This has not been discussed, but cards can sometimes use areas of memory directly.]
- The file
/etc/modules.conf[Also sometimes called
/etc/conf.modules, but now deprecated.] contains default options for
modprobe, instead of our giving them on the
modprobecommand-line. This is the preferred and most common way of giving module options. Our Ethernet example becomes:
- Having set up an
/etc/modules.conffile allows module dynamic loading to take place. This means that the kernel automatically loads the necessary module whenever the device is required (as when
ifconfigis first used for Ethernet devices). The kernel merely tries an
/sbin/modprobe eth0, and the
aliasline hints to
modprobeto actually run
/sbin/modprobe wd. Further, the
optionsline means to run
/sbin/modprobe wd irq=9 io=0x300 mem=0xd0000 mem_end=0xd4000. In this way,
/etc/modules.confmaps devices to drivers.
You might like to see a complete summary of all module options with examples of each of the five ways of passing options. No such summary exists at this point, simply because there is no overall consistency and because people are mostly interested in getting one particular device to work, which will doubtless have peculiarities best discussed in a specialized document. Further, some specialized modules are mostly used in compiled-out form, whereas others are mostly used in compiled-in form.
To get an old or esoteric device working, it is best to read the appropriate HOWTO
Sound-HOWTO. The device could also be documented in
/usr/linux-<version>/Documentation/ or under one of its subdirectories like
This is documentation written by the driver
authors themselves. Of particular interest is the file
/usr/src/linux/Documentation/networking/net-modules.txt, which, although
outdated, has a fairly comprehensive list of networking modules and the module
options they take. Another source of documentation is the driver C code itself, as in
aha1542.c example above. It may explain the
/etc/modules.conf options to use but will often be quite cryptic. A driver is
often written with only one of compiled-in or compiled-out support in mind (even
though it really supports both). Choose whether to compile-in or
compiled-out based on what is implied in the documentation or C source.
Further examples on getting common devices to work now follow but only a few devices are discussed. See the documentation sources above for more info. We concentrate here on what is normally done.
Plug-and-Play (PnP) ISA sound cards (like SoundBlaster cards) are possibly the more popular of any cards that people have gotten to work under LINUX. Here, we use the sound card example to show how to get a PnP ISA card working in a few minutes. This is, of course, applicable to cards other than sound.
A utility called
isapnp takes one argument, the file
/etc/isapnp.conf, and configures all ISA Plug-and-Play
devices to the IRQs and I/O ports specified therein.
/etc/isapnp.conf is a complicated file but can be generated
pnpdump outputs an
isapnp.conf file to stdout, which contains IRQ and I/O port
values allowed by your devices. You must edit these to unused
values. Alternatively, you can use
pnpdump --config to get a
/etc/isapnp.conf file with the correct IRQ, I/O port, and DMA
channels automatically guessed from an examination of the
/proc/ entries. This comes down to
which gets any ISA PnP card configured with just two commands.
Note that the
file can be used to make
using certain IRQ and I/O ports. Mine contains
to avoid conflicting with my parallel port.
isapnp /etc/isapnp.conf must be run each time at
boot and is probably already in your startup scripts.
Now that your ISA card is enabled, you can install the necessary modules.
You can read the
/etc/isapnp.conf file and also
output above to reference the I/O ports to the correct module options:
tail -f /var/log/messages /var/log/syslog, and then at
another terminal type:
If you get no kernel or other errors, then the devices are working.
Now we want to set up dynamic loading of the module. Remove
all the sound and other modules with
rmmod -a (or manually),
and then try:
You should get a kernel log like this:
You should get a kernel log like this one:
If you had to comment out the
then a kernel message like
modprobe: Can't locate module
sound-slot-0 would result. This indicates that the kernel is
/sbin/modprobe sound-slot-0: a cue to insert an
alias line. Actually,
sound-slot-0 means a card that should
supply all of these. The
post-install option means to run an
additional command after installing the
sb module; this takes
care of the Adlib sequencer driver. [I was tempted to try
post-install line and adding a
alias sound-service-0-1 adlib_card. This works, but not if
The parallel port module is much less trouble:
Merely make sure that your IRQ and I/O port match those in your CMOS (see Section 3.3), and that they do not conflict with any other devices.
For old ISA cards with jumpers, you will need to check your
/proc/ files for unused IRQ and I/O ports and then physically
set the jumpers. Now you can do a
modprobe as usual, for example:
Of course, for dynamic loading, your
/etc/modules.conf file must
have the lines:
On some occasions you will come across a card that has software configurable jumpers, like PnP, but that can only be configured with a DOS utility. In this case compiling the module into the kernel will cause it to be autoprobed on startup without needing any other configuration.
A worst case scenario is a card whose make is unknown, as well
its IRQ and I/O ports. The chip number on the card can sometimes give you a
grep the kernel sources for this number), but not always. To get
this card working, compile in support for several modules, one of which the
card is likely to be. Experience will help you make better guesses. If one of
your guesses is correct, your card will almost certainly be discovered on
reboot. You can find its IRQ and I/O port values in
/proc/ or you can run
dmesg to see the autoprobe message line; the message will begin with
As explained, PCI devices almost never require IRQ or I/O ports to be given as options. As long as you have the correct module, a simple
will always work. Finding the correct module can still be a problem,
however, because suppliers will call a card all sorts of marketable things
besides the actual chipset it is compatible with. The utility
scanpci (which is actually part of X) checks your PCI slots for
PCI devices. Running
scanpci might output something like:
faithfully outputs three modules
tulip.o, of which two are correct. On another system
and the same
tulip.o (the former of which was correct), and
Macronix (or even
tulip.o, which hung the machine. I have yet to get that card working,
although Eddie across the room claims he got a similar card working fine.
Cards are cheap--there are enough working brands so that you don't have to waist
your time on difficult ones.
PCI supports the useful concept that every vendor and device have unique hex IDs.
For instance, Intel has chosen to represent themselves by the completely
random number 0x8086 as their vendor ID. PCI cards will provide their IDs on request.
You will see numerical values listed in the output of
cat /proc/pci, especially if the respective utility cannot look up
the vendor name from the ID number. The file
/usr/share/misc/pci.ids on Debian) from the
pciutils package contains a complete
table of all IDs and their corresponding names. The
kudzu package also has
containing the information we are really
looking for: ID to kernel module mappings. This enables you to
use the intended scientific method for locating
the correct PCI module from the kernel's
The file format is easy to understand, and as an exercise you should
try writing a shell script to do the lookup automatically.
scanpci output just above also shows the popular Ensoniq
sound card, sometimes built into motherboards. Simply adding the line
modules.conf file will get this card working.
It is relatively easy to find the type of card from the card itself--Ensoniq
cards actually have es1371 printed on one of the chips.
If your card is not listed in
then you might be able to get a driver from
Open Sound <
http://www.opensound.com>. If you still can't find a
driver, complain to the manufacturer by email.
There are a lot of sound (and other) cards whose manufacturers refuse to supply the Free software community with specs. Disclosure of programming information would enable LINUX users to buy their cards; Free software developers would produce a driver at no cost. Actually, manufacturers' reasons are often just pig-headedness.
The ALSA (Advanced Linux Sound
http://www.alsa-project.org/>) project aims to provide better kernel sound support. If
your card is not supported by the standard kernel or you are not getting
the most out of the standard kernel drivers, then do check this web site.
If you have more than one Ethernet card, you can easily specify both in your
modules.conf file, as shown in Section 42.5 above.
Modules compiled into the kernel only probe a single card (
default. Adding the line
eth3 to be probed
as well. Further, replacing the
0's with actual values can force
certain interfaces to certain physical cards. If all your cards are
PCI, however, you will have to get the order of assignment by
If you have two of the same card, your kernel may complain when
you try to load the same module twice. The
-o option to
insmod specifies a different internal name for the driver to trick the
kernel into thinking that the driver is not really loaded:
However, with the following two PCI cards that deception was not necessary:
SCSI (pronounced scuzzy) stands for Small Computer System Interface. SCSI is a ribbon, a specification, and an electronic protocol for communication between devices and computers. Like your IDE ribbons, SCSI ribbons can connect to their own SCSI hard disks. SCSI ribbons have gone through some versions to make SCSI faster, the latest ``Ultra-Wide'' SCSI ribbons are thin, with a dense array of pins. Unlike your IDE, SCSI can also connect tape drives, scanners, and many other types of peripherals. SCSI theoretically allows multiple computers to share the same device, although I have not seen this implemented in practice. Because many UNIX hardware platforms only support SCSI, it has become an integral part of UNIX operating systems.
SCSIs also introduce the concept of LUNs (which
stands for Logical Unit Number), Buses, and ID.
These are just numbers given to each device in order of the SCSI cards
you are using (if more than one), the SCSI cables on those cards, and
the SCSI devices on those cables--the SCSI
standard was designed to support a great many of these. The kernel
assigns each SCSI drive in sequence as it finds them:
/dev/sdb, and so on, so these details are usually irrelevant.
An enormous amount should be said on SCSI, but the bare bones is that for
90% of situations,
insmod <pci-scsi-driver> is all you are going to
need. You can then immediately begin accessing the device through
/dev/sd? for disks,
/dev/st? for tapes,
/dev/scd? for CD-ROMs, or
scanners. [Scanner user programs will have docs on what devices they
access.] SCSIs often also come with their own BIOS
that you can enter on startup (like your CMOS). This will enable you to set
certain things. In some cases, where your distribution compiles-out certain
modules, you may have to load one of
sg.o, respectively. The core
module may also need loading, and
/dev/ devices may need to be
created. A safe bet is to run
to ensure that all necessary device files exist in the first place.
It is recommended that you compile into your kernel support for your SCSI card (also called the SCSI Host Adapter) that you have, as well as support for tapes, CD-ROMs, etc. When your system next boots, everything will just autoprobe. An example system with a SCSI disk and tape gives the following at bootup:
You should also check Section 31.5 to find out how to boot SCSI disks when the needed module... is on a file system... inside a SCSI disk... that needs the module.
This is the most important section to read regarding SCSI. You may be used to IDE ribbons that just plug in and work. SCSI ribbons are not of this variety; they need to be impedance matched and terminated. These are electrical technicians' terms. Basically, it means that you must use high-quality SCSI ribbons and terminate your SCSI device. SCSI ribbons allow many SCSI disks and tapes to be connected to one ribbon. Terminating means setting certain jumpers or switches on the last devices on the ribbon. It may also mean plugging the last cable connector into something else. Your adapter documentation and disk documentation should explain what to do. If you terminate incorrectly, everything may work fine, but you may get disk errors later in the life of the machine. Also note that some newer SCSI devices have automatic termination.
Cooling is another important consideration. When the documentation for a disk drive recommends forced air cooling for that drive, it usually means it. SCSI drives get extremely hot and can burn out in time. Forced air cooling can mean as little as buying a cheap circuit box fan and tying it in a strategic position. You should also use very large cases with several inches of space between drives. Anyone who has opened up an expensive high end server will see the attention paid to air cooling.
A system with an ATAPI (IDE CD-Writer and ordinary CD-ROM will display a message at bootup like,
Note that these devices should give BIOS messages before
LILO: starts to indicate that
they are correctly installed.
/etc/modules.conf lines to get the CD-writer
alias scd0 line must be omitted if
compiled into the kernel--search your
directory. Note that the kernel does not support ATAPI CD-Writers directly.
emulates a SCSI adapter on
behalf of the ATAPI CD-ROM. CD-Writer
software expects to speak to
/dev/scd?, and the
ide-scsi module makes this device appear like a real
SCSI CD writer. [Real SCSI CD
writers are much more expensive.] There is
one caveat: your ordinary IDE CD-ROM driver,
ide-cd, will also want to probe your CD writer as if it were a normal
ignore option makes the
ide-cd module overlook
any drives that should not be probed--on this system, these would be the
hard disk, CD writer, and non-existent secondary master. However,
there is no way of giving an
ignore option to a compiled-in
ide-cd module (which is how many distributions ship), so
An alternative is to compile in support for
ide-scsi and completely
leave out support for
ide-cd. Your normal CD-ROM will work perfectly
as a read-only CD-ROM under SCSI emulation. [Even with music CDs.]This means setting the relevant sections of your kernel configuration menu:
No further configuration is needed, and on bootup, you will find messages like:
If you do have a real SCSI writer, compiling in support
for your SCSI card will detect it in a similar fashion. Then, for this example,
the device on which to
mount your CD-ROM is
For actually recording a CD, the
cdrecord command-line program
is simple and robust, although there are also many pretty graphical front ends.
To locate your CD ID, run
which will give a comma-separated numeric sequence. You can then
use this sequence as the argument to
On my machine I type
to create an ISO9660 CD-ROM out of everything below a
/my/directory. This is most useful for backups. (The
-a option should
be omitted in newer versions of this command.) Beware not to exceed the speed limit of your
You don't need to load any modules to get your mouse and modem to work.
Regular serial devices (COM1 through COM4 under DOS/Windows) will
autoprobe on boot and are available as
/dev/ttyS3. A message on boot, like
will testify to their correct detection.
On the other hand, multiport serial
cards can be difficult to configure. These
devices are in a category all of their own. Most use a chip called the
16550A UART (Universal Asynchronous Receiver Transmitter),
which is similar to that of your built-in serial port.
The kernel's generic serial code supports them, and
you will not need a separate driver. The UART really is the serial
port and comes in the flavors
To get these cards working requires the use of the
setserial command. It is
used to configure the kernel's built-in serial driver. A typical example is an
8-port non-PnP ISA card with jumpers set to unused IRQ
0x1BF. Note that unlike most devices, many
serial devices can share the same IRQ. [The reason is that serial
devices set an I/O port to tell which device is sending the interrupt. The CPU
just checks every serial device whenever an interrupt comes in.] The
card is configured with this script:
You should immediately be able to use these devices as regular ports. Note
that you would expect to see the interrupt in use under
/proc/interrupts. For serial
devices this is only true after data actually
starts to flow. However, you can check
/proc/tty/driver/serial to get
more status information. The
setserial man page contains more about
different UARTs and their compatibility problems. It also explains
autoprobing of the UART, IRQ, and I/O ports (although
it is better to be sure of your card and never use autoprobing).
Serial devices give innumerable problems. There is a very long
Serial-HOWTO that will help you solve most of them; It goes into
more technical detail. It will also explain special kernel support for
many ``nonstandard'' cards.
Elsewhere in this book I refer only to ordinary external modems that connect
to your machine's auxiliary serial port. However, internal ISA modem
cards are cheaper and include their own internal serial port. This card
can be treated as above, like an ISA multiport serial card with only one
port: just set the I/O port and IRQ jumpers and then run
setserial /dev/ttyS3... .
Beware that a new variety of modem has been invented called the
``win-modem.'' These cards are actually just sound cards. Your operating
system has to generate the signals needed to talk the same protocol as
a regular modem. Because the CPU has to be very fast to do this, such
modems were probably not viable before 1997 or so.
http://www.linmodems.org/ are three resources that cover
BootPrompt-HOWTO contains an exhaustive list of things that
can be typed at the boot prompt to do interesting things
like NFS root mounts.
This document is important to read if only to get
an idea of the features that LINUX supports.
lilo. Details on each of these steps follow.
The LINUX kernel is available from various places as
but primarily from the
LINUX kernel's home <
The kernel can easily be unpacked with
and possibly patched with (see Section 20.7.3):
2.4.0-test6 kernel source tree is now a
kernel source tree. You will often want to patch
the kernel with features that Linus did not include, like security patches or
commercial hardware drivers.
Important is that the following include directories point to the correct directories in the kernel source tree:
Before continuing, you should read the
/usr/src/linux/Documentation/) to find out
what is required to build the kernel. If you have a kernel
source tree supplied by your distribution, everything will
already be up-to-date.
(A kernel tree that has suffered from previous builds may need you to run
before anything else. This completely cleans the tree, as though you had just unpacked it.)
There are three kernel configuration interfaces.
The old line-for-line
y/n interface is painful to use. For
a better text mode interface, you can type
otherwise, under X enter
to get the graphical configurator. For this discussion, I assume that you are using the text-mode interface.
The configure program enables you to specify an enormous
number of features. It is advisable to skim through all the sections to get a
feel for the different things you can do. Most options are about specifying
whether you want a feature
[*] compiled into the kernel image,
[M] compiled as a module, or
[ ] not compiled at all.
You can also turn off module support altogether from
Loadable module support -->. The kernel configuration
is one LINUX program that offers lots of help--select
< Help > on
any feature. The raw help file is
(nearly 700 kilobytes) and is worth reading.
When you are satisfied with your selection of options, select
< Exit >
save your new kernel configuration.
The kernel configuration is saved in a file
time you run
your configuration will default to these settings.
contains defaults to use in the
absence of a
.config file. Note that the command
make mrproper removes
Your distribution will probably have a kernel source package ready to build.
This package is better to use than downloading the source yourself because all the default
build options will be present; for instance, RedHat 7.0 comes with the file
can be copied over the
/usr/src/linux-2.2.16/.config to build a kernel
optimized for SMP (Symmetric Multiprocessor Support)
with all of RedHat's defaults enabled. It also comes with a
defconfig file to
build kernels identical to those of RedHat. Finally,
RedHat would have applied many patches to add features that may be
time consuming to do yourself. The same goes for Debian.
You should try to enable or ``compile-in'' features rather than disable anything, since the default RedHat kernel supports almost every kernel feature, and later it may be more convenient to have left it that way. On the other hand, a minimal kernel will compile much faster.
Run the following commands to build the kernel; this process may take anything from
a few minutes to several hours, depending on what you have enabled. After
each command completes, check the last few messages for errors (or check the return
$?), rather than blindly typing the next commands.
make modules_install would have installed all modules
/lib/modules/<version>. [You may like to clear out this
directory at some point and rerun
make modules_install, since stale
modules cause problems with
The kernel image itself,
/usr/src/linux/System.map are two other files
by the build.
These must be copied to
/boot/, possibly creating neat symlinks:
lilo.conf may be
edited as described in Chapter 31.
Most people now forget to run
find their system unbootable.
lilo, making sure that you have left your
old kernel in as an option, in case you need to return to it.
Also make a boot floppy from your
kernel, as shown in Section 31.4.
Next: 43. The X Window Up: rute Previous: 41. Point-to-Point Protocol   Contents
Только зарегистрированные пользователи могут оценивать и комментировать статьи.