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
modules, the
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
lilo.
The kernel in
/boot/ is compressed. That is, it
is
gzip compressed 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.2 there were about 400,
modules totaling about 9 megabytes.
Modules are actually just shared object files, like the
.o files 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
test program 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.map file, also in
/boot.
It is used by
klogd to resolve kernel address references
to symbols, so as to write logs about them, and then also by
depmod to work out module dependencies (what
modules need what other modules to be loaded first).
Finally, the kernel headers
/usr/src/linux/include
are used when certain packages are built.
The ``various support daemons'' should be running
already. Since
2.2, these have been reduced to
klogd
only. The other kernel daemons that appear to be running are
generated by the kernel itself.
The kernel is versioned like other packages:
linux-major
.minor
.patch.
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.2.17,
and
2.4.0 was soon to be released.
By the time you read this,
2.4.0
will be available. This chapter should
be entirely applicable to future stable releases of
2.4.
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 =
0,
1,..., when it loads;
and the Sound module onto device major =
14, minor =
3
(
/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)
Modules sometimes need other modules to be present in order to
load. If you try to load a module and it gives
<module-name>:
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
file
/lib/modules/<version>/modules.dep and is
generated automatically by your startup scripts with the command
/sbin/depmod -a
although you can run it manually at any time. The
lsmod
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
/proc/ directory:
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
3: 104851 XT-PIC serial
showing that several hundred interrupts were since
received. Another useful entry is
/proc/devices, which
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.
lilo passes 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]:
linux aha1542=<portbase>[,<buson>,<busoff>[,<dmaspeed>]]
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.
2.
If you are using
LOADLIN.EXE or some other
DOS or Windows kernel loader, then it, too, can take similar options.
I will not go into these.
3.
/etc/lilo.conf can 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
lilo.conf line is
This is the most common way of giving kernel boot options.
4.
The
insmod and
modprobe commands
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
Note that the
0xd0000,0xd4000 are only applicable
to a few Ethernet modules and are usually omitted. Also, the
0's in
ether=0,0,eth1 mean to try autodetect. To find out what
options a module will take, you can use the
modinfo command which
shows that the
wd driver 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.]
5
[root@cericon]# modinfo -p /lib/modules/<version>/net/wd.o ( [root@cericon]# modinfo -p /lib/modules/<version>/kernel/drivers/net/wd.o ) io int array (min = 1, max = 4) irq int array (min = 1, max = 4) mem int array (min = 1, max = 4) mem_end int array (min = 1, max = 4)
5.
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
modprobe
command-line. This is the preferred and most
common way of giving module options. Our Ethernet example becomes:
alias eth0 wd alias eth1 de4x5 options wd irq=9 io=0x300 mem=0xd0000 mem_end=0xd4000
Having set up an
/etc/modules.conf file allows module
dynamic loading to take place. This means that the kernel
automatically loads the necessary module whenever the device is
required (as when
ifconfig is first used for Ethernet devices). The kernel merely
tries an
/sbin/modprobe eth0, and the
alias line hints
to
modprobe to actually run
/sbin/modprobe wd.
Further, the
options line means to run
/sbin/modprobe
wd irq=9 io=0x300 mem=0xd0000 mem_end=0xd4000. In this way,
/etc/modules.conf maps 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
documents:
BootPrompt-HOWTO,
Ethernet-HOWTO, and
Sound-HOWTO. The device could also be documented in
/usr/linux-<version>/Documentation/ or under one of its subdirectories like
sound/ and
networking/.
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
the
aha1542.c example above. It may explain the
/etc/lilo.conf or
/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
with the
pnpdump utility.
pnpdump outputs an
example
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
5
[root@cericon]# pnpdump --config | grep -v '^\(#.*\|\)$' > /etc/isapnp.conf [root@cericon]# isapnp /etc/isapnp.conf Board 1 has Identity c9 00 00 ab fa 29 00 8c 0e: CTL0029 Serial No 44026 [checksum c9] CTL0029/44026[0]{Audio }: Ports 0x220 0x330 0x388; IRQ5 DMA1 DMA5 --- Enabled OK CTL0029/44026[1]{IDE }: Ports 0x168 0x36E; IRQ10 --- Enabled OK CTL0029/44026[2]{Game }: Port 0x200; --- Enabled OK
which gets any ISA PnP card configured with just two commands.
Note that the
/etc/isapnp.gone
file can be used to make
pnpdump avoid
using certain IRQ and I/O ports. Mine contains
IO 0x378,2 IRQ 7
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
isapnp's
output above to reference the I/O ports to the correct module options:
5 10
alias sound-slot-0 sb alias sound-service-0-0 sb alias sound-service-0-1 sb alias sound-service-0-2 sb alias sound-service-0-3 sb alias sound-service-0-4 sb alias synth0 sb post-install sb /sbin/modprobe "-k" "adlib_card" options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330 options adlib_card io=0x388 # FM synthesizer
Now run
tail -f /var/log/messages /var/log/syslog, and then at
another terminal type:
depmod -a modprobe sb
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:
aumix
You should get a kernel log like this:
Sep 24 00:45:19 cericon kernel: Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996 Sep 24 00:45:19 cericon kernel: SB 4.13 detected OK (240)
Then try:
playmidi <somefile>.mid
You should get a kernel log like this one:
5
Sep 24 00:51:34 cericon kernel: Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996 Sep 24 00:51:34 cericon kernel: SB 4.13 detected OK (240) Sep 24 00:51:35 cericon kernel: YM3812 and OPL-3 driver Copyright (C) by Hannu Savolainen, Rob Hooft 1993-1996
If you had to comment out the
alias lines,
then a kernel message like
modprobe: Can't locate module
sound-slot-0 would result. This indicates that the kernel is
attempting a
/sbin/modprobe sound-slot-0: a cue to insert an
alias line. Actually,
sound-service-0-0,
1,
2,
3,
4 are
the
/dev/mixer,
sequencer,
midi,
dsp,
audio
devices,
respectively.
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
removing the
post-install line and adding a
alias sound-service-0-1 adlib_card. This works, but not if
you run
aumix before
playmidi, **shrug**.]
Here I demonstrate non-PnP ISA cards and PCI cards, using Ethernet
devices as an example. (NIC stands for Network Interface Card, that is, an
Ethernet 10 or 100 Mb card.)
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:
modinfo -p ne modprobe ne io=0x300 irq=9
Of course, for dynamic loading, your
/etc/modules.conf file must
have the lines:
alias eth0 ne options ne io=0x300 irq=9
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
hint (
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
eth0: ... and contain some information about the driver.
This information can be used if you decide later to use modules instead of
your custom kernel.
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
modprobe <module>
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:
5 10
. . . pci bus 0x0 cardnum 0x09 function 0x0000: vendor 0x1011 device 0x0009 Digital DC21140 10/100 Mb/s Ethernet pci bus 0x0 cardnum 0x0b function 0x0000: vendor 0x8086 device 0x1229 Intel 82557/8/9 10/100MBit network controller pci bus 0x0 cardnum 0x0c function 0x0000: vendor 0x1274 device 0x1371 Ensoniq es1371
Another utility is
lspci from
the
pciutils package,
which gives comprehensive information where
scanpci sometimes
gives none. Then a simple script (kernel
2.4 paths in parentheses again),
5
for i in /lib/modules/<version>/net/* ; do strings $i \ | grep -q -i 21140 && echo $i ; done ( for i in /lib/modules/<version>/kernel/drivers/net/* \ ; do strings $i | grep -q -i 21140 && echo $i ; done ) for i in /lib/modules/<version>/net/* ; do strings $i \ | grep -q -i 8255 && echo $i ; done ( for i in /lib/modules/<version>/kernel/drivers/net/* \ ; do strings $i | grep -q -i 8255 && echo $i ; done )
faithfully outputs three modules
de4x5.o,
eepro100.o,
and
tulip.o, of which two are correct. On another system
lspci
gave
and the same
for...
grep...
Accton gave
rtl8139.o and
tulip.o (the former of which was correct), and
for...
grep...
Macronix (or even
987) gave
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
lspci,
scanpci, and
cat /proc/pci, especially if the respective utility cannot look up
the vendor name from the ID number. The file
/usr/share/pci.ids
(
/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
a table
/usr/share/kudzu/pcitable
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
/proc/pci data.
The file format is easy to understand, and as an exercise you should
try writing a shell script to do the lookup automatically.
The
scanpci output just above also shows the popular Ensoniq
sound card, sometimes built into motherboards. Simply adding the line
alias sound es1371
to your
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
/usr/src/<version>/Documentation/sound/,
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
Architecture<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 (
eth0) by
default. Adding the line
will cause
eth1,
eth2, and
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
experimentation.
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:
alias eth0 3c509 alias eth1 3c509 options eth0 -o 3c509-0 io=0x280 irq=5 options eth1 -o 3c509-1 io=0x300 irq=7
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/sda,
/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
/dev/sg? for
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
sd_mod.o,
st.o,
sr_mod.o, or
sg.o, respectively. The core
scsi_mod.o
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:
5 10 15 20 25 30
(scsi0) <Adaptec AIC-7895 Ultra SCSI host adapter> found at PCI 0/12/0 (scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs (scsi0) Cables present (Int-50 YES, Int-68 YES, Ext-68 YES) (scsi0) Illegal cable configuration!! Only two (scsi0) connectors on the SCSI controller may be in use at a time! (scsi0) Downloading sequencer code... 384 instructions downloaded (scsi1) <Adaptec AIC-7895 Ultra SCSI host adapter> found at PCI 0/12/1 (scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs (scsi1) Downloading sequencer code... 384 instructions downloaded scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.28/3.2.4 <Adaptec AIC-7895 Ultra SCSI host adapter> scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.28/3.2.4 <Adaptec AIC-7895 Ultra SCSI host adapter> scsi : 2 hosts. (scsi0:0:0:0) Synchronous at 40.0 Mbyte/sec, offset 8. Vendor: FUJITSU Model: MAE3091LP Rev: 0112 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 (scsi0:0:3:0) Synchronous at 10.0 Mbyte/sec, offset 15. Vendor: HP Model: C1533A Rev: A708 Type: Sequential-Access ANSI SCSI revision: 02 Detected scsi tape st0 at scsi0, channel 0, id 3, lun 0 scsi : detected 1 SCSI tape 1 SCSI disk total. SCSI device sda: hdwr sector= 512 bytes. Sectors= 17826240 [8704 MB] [8.7 GB] . . . Partition check: sda: sda1 hda: hda1 hda2 hda3 hda4 hdb: hdb1
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,
hda: FUJITSU MPE3084AE, ATA DISK drive hdb: CD-ROM 50X L, ATAPI CDROM drive hdd: Hewlett-Packard CD-Writer Plus 9300, ATAPI CDROM drive
Note that these devices should give BIOS messages before
LILO: starts to indicate that
they are correctly installed.
The
/etc/modules.conf lines to get the CD-writer
working are:
alias scd0 sr_mod # load sr_mod upon access of /dev/scd0 alias scsi_hostadapter ide-scsi # SCSI hostadaptor emulation options ide-cd ignore="hda hdc hdd" # Our normal IDE CD is on /dev/hdb
The
alias scd0 line must be omitted if
sr_mod is
compiled into the kernel--search your
/lib/modules/<version>/
directory. Note that the kernel does not support ATAPI CD-Writers directly.
The
ide-scsi module
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
CD-ROM. The
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
read on.
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:
5
<*> Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support < > Include IDE/ATAPI CDROM support <*> SCSI emulation support <*> SCSI support <*> SCSI CD-ROM support [*] Enable vendor-specific extensions (for SCSI CDROM) <*> SCSI generic support
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
/dev/scd0 and
your CD-Writer,
/dev/scd1.
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
cdrecord -scanbus
which will give a comma-separated numeric sequence. You can then
use this sequence as the argument to
cdrecord's
dev= option.
On my machine I type
to create an ISO9660 CD-ROM out of everything below a
directory
/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
CD writer.
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/ttyS0 through
/dev/ttyS3. A message on boot, like
Serial driver version 4.27 with MANY_PORTS MULTIPORT SHARE_IRQ enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A
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
8250,
16450,
16550,
16550A,
16650,
16650V2, and
16750.
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
5 and
ports
0x180-
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://linmodems.technion.ac.il/,
http://www.idir.net/~gromitkc/winmodem.html, and
http://www.linmodems.org/ are three resources that cover
these modems.
The
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.
cd /usr/src/linux/ make mrproper make menuconfig make dep make clean make bzImage make modules make modules_install cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-<version> cp /usr/src/linux/System.map /boot/System.map-<version>
Finally, edit
/etc/lilo.conf and
run
lilo. Details on each of these steps follow.
The LINUX kernel is available from various places as
linux-?
.?
.?
.tar.gz,
but primarily from the
LINUX kernel's home<ftp://ftp.kernel.org/pub/linux/kernel/>.
The kernel can easily be unpacked with
5
cd /usr/src mv linux linux-OLD tar -xzf linux-2.4.0-test6.tar.gz mv linux linux-2.4.0-test6 ln -s linux-2.4.0-test6 linux cd linux
bzip2 -cd ../patch-2.4.0-test7.bz2 | patch -s -p1 cd .. mv linux-2.4.0-test6 linux-2.4.0-test7 ln -sf linux-2.4.0-test7 linux cd linux make mrproper
Your
2.4.0-test6 kernel source tree is now a
2.4.0-test7
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
Changes
file (under
/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
make mrproper
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
make menuconfig
otherwise, under X enter
make xconfig
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
/usr/src/linux/Documentation/Configure.help
(nearly 700 kilobytes) and is worth reading.
When you are satisfied with your selection of options, select
< Exit >
and select
save your new kernel configuration.
The kernel configuration is saved in a file
/usr/src/linux/.config. Next
time you run
make menuconfig,
your configuration will default to these settings.
The file
/usr/src/linux/arch/i386/defconfig
contains defaults to use in the
absence of a
.config file. Note that the command
make mrproper removes
the
.config file.
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
/usr/src/linux-2.2.16/configs/kernel-2.2.16-i586-smp.config, which
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
custom
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
code,
$?), rather than blindly typing the next commands.
5
make dep && \ make clean && \ make bzImage && \ make modules && \ make modules_install
The command
make modules_install would have installed all modules
into
/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
depmod -a.]
The kernel image itself,
/usr/src/linux/arch/i386/boot/bzImage,
and
/usr/src/linux/System.map are two other files
produced
by the build.
These must be copied to
/boot/, possibly creating neat symlinks:
Finally, your
lilo.conf may be
edited as described in Chapter 31.
Most people now forget to run
lilo and
find their system unbootable.
Do run
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.
![[*]](crossref.png)