- Linux is a Kernel that comes with built-in Drivers for many types of
- Yet, with newer Hardware, the installation procedure does not always
manage to configure a proper Driver...
- ...Or the Driver is not found in our distribution's Kernel.
- In these cases, we want to be able to find the right Driver, install
it and configure it to work properly.
- In this lecture, we will get an initial idea of how to do that.
Once again, remember what sets off "the hitch-hikers guide to the galaxy"
from "the encyclopedia Galactica": It has, written on its top, the
phrase: Don't Panic!
The Linux Kernel
- Is a computer program, that acts as the operating system.
- Allows applications to access the Hardware, in a more-or-less generic
- Gets loaded when the system starts executing, and launches processes that
allow us to login and run programs.
- Is made of a 'core' residing in a single file, and a bunch of smaller
Modules that are only loaded if they are needed.
The Kernel, The Processes And The Hardware
If we draw an abstract layout of the layout of the operating system, it could
look like the following drawing:
- In order to configure a Driver for some Hardware, we first need to
identify it properly.
- Often, the name of the product we bought is unknown, or is too generic.
- What we are most interested in, is the name of the manufacturer and model
of the chips (chip-sets) found on our Hardware Device...
- ... Because this is what the Driver eventually communicates with.
The lspci Command
- Allows us to identify the type of Hardware we have on our system.
- Provided that these are PCI cards (not older ISA cards).
[choo@simey ~]$ /sbin/lspci
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 3189
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device b168
00:0a.0 Communication controller: Conexant HSF 56k HSFi Modem (rev 01)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C (rev 10)
00:0c.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)
00:0c.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 0a)
00:10.0 USB Controller: VIA Technologies, Inc. USB (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. USB (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. USB (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc.: Unknown device 3177
00:11.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C (rev 10)
01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX440] (rev a3)
A modem, 2 sound cards, 2 network cards, a USB interface, an IDE controller
and a screen controller.
Using Your Eyes
- Note: use this method if the Kernel did not recognize
some Hardware Device (e.g. Because the Hardware was first sold in the
world after your Linux Distribution was released).
- Open up your computer's enclosing box (if the Device is internal).
- Search for the Hardware Device you want to look at.
- Look on the chips on it, for the largest one, and read its label.
- Copy down the entire contents, and place parts of it in a Google
Verification Via The /proc Directory
- The /proc directory is a virtual directory, allowing direct interaction
with the running Linux Kernel.
- When we try to print one of its files, the Kernel generates its
contents on-the-fly. There are no real disk files under this directory.
- Some files interesting for Hardware diagnostics (view them with
- /proc/interrupts - a list of
interrupt numbers (IRQs) currently in use by different Drivers.
- /proc/ioports - a list of
I/O addresses currently in use by Drivers.
- /proc/pci - info about PCI Devices.
- /proc/cpuinfo - info about our CPU.
The /dev directory
- The standard location for all Device files in the system...
- ...But one can create Device files in other directories (e.g.
in RedHat's installation process, the Device files for the hard disks
are created in the /tmp directory).
- Examples of conventional file names:
- hda - first (a) IDE Device (hard disk, CDROM).
- hdb3 - 3rd (3) partition of second (b) IDE
Device (must be a hard disk. CDROMs
have no partitions).
- ttyS0 - first serial port ("COM1").
- sda1 - 1st (1) partition of first (a) SCSI
Device (hard-disk, an emulated SCSI
- lp0 - first parallel port (LPT1).
Character Device Vs. Block Device
- A Character ('c') Device is one with which the Driver communicates
by sending and receiving single characters (bytes, octets).
- A Block ('b') Device is one with which the Driver communicates by sending
entire blocks of data.
- Examples for Character Devices: serial ports, parallel ports, sounds
- Examples for Block Devices: hard disks, USB cameras, Disk-On-Key.
- For the user, the type of the Device (block or character) does not
matter - you just care that this is a hard disk partition or a sound card.
- Driver programmers, however, do care, but that's beyond our scope.
- In order to reduce the size of the Linux Kernel, it may be split into
a 'core', and a large set of Kernel Modules.
- A Kernel Module is a small file that may be loaded into the running
Kernel, and unloaded, at will (the next generation of the Linux kernel
will not allow unloading modules, unless told otherwise).
- Many functions of the Kernel may either be compiled into the Kernel
directly, or compiled as Modules.
- This design makes it faster to load the Kernel (no need to load
and initialize un-needed Modules), as well as developing Drivers
(if you have a bug, just unload the Module, fix it, recompile and
load it again).
Listing Loaded Modules With lsmod
In order to see the list of currently loaded Modules, use the
[choo@simey ~]$ /sbin/lsmod
Module Size Used by Not tainted
ppp_synctty 6368 0 (unused)
ppp_async 8032 1
ppp_generic 23692 3 [ppp_synctty ppp_async]
slhc 6220 0 [ppp_generic]
ipt_LOG 4384 19 (autoclean)
ipt_TCPMSS 3168 1 (autoclean)
iptable_nat 19668 1 (autoclean)
ip_conntrack 20268 1 (autoclean) [iptable_nat]
iptable_filter 2464 1 (autoclean)
ip_tables 13632 6 [ipt_LOG ipt_TCPMSS iptable_nat iptable_filter]
vfat 11804 1 (autoclean)
fat 36184 0 (autoclean) [vfat]
ext3 64800 3 (autoclean)
jbd 47924 3 (autoclean) [ext3]
emu10k1 60832 1
ac97_codec 12256 0 [emu10k1]
sound 69260 0 [emu10k1]
soundcore 6212 7 [emu10k1 sound]
mousedev 5024 1
hid 20608 0 (unused)
input 5696 0 [mousedev hid]
ehci-hcd 16864 0 (unused)
usb-uhci 24292 0 (unused)
usbcore 71104 1 [hid ehci-hcd usb-uhci]
The /lib/modules Directory
- Contains the Modules for the different Kernel versions we have installed.
- One directory per Kernel, named after the Kernel's version number.
- Modules are split into directories, based on categories:
- pcmcia - PCMCIA Drivers, for laptops.
- kernel/net - network-related Modules
(firewall, extra protocols support, etc.)
- kernel/drivers - Drivers for various types of
Hardware (including network
- kernel/fs - file-systems support (ext3,
- kernel/arch - Architecture-specific support
(e.g. Drivers to handle features of a
a specific CPU or motherboard).
Loading And Unloading Kernel Modules - insmod/rmmod
Handling Kernel Module Dependencies - depmod and modprobe
- Modules could depend on each other. For example, to load the Module
'lm78', we need to first load 'i2c-core' and 'i2c-proc'.
- The depmod command builds a list of Module
dependencies - i.e. for each Module, which other Modules it needs, in
order to load. Run it as:
[root@simey ~]# depmod -a
depmod: *** Unresolved symbols in
depmod: *** Unresolved symbols in
depmod: *** Unresolved symbols in
- In order to have the system take care of these loading dependencies
automatically, load a Module using the modprobe
[root@simey ~]# modprobe lm78
or, for a more verbose output:
[root@simey ~]# modprobe -v lm78
Symbol version prefix ''
The /etc/modules.conf file
- Contains 'default' parameters for Modules we use often (e.g. network
Drivers, sound cards, etc.)
- commonly used lines:
- Note: module options may also be supplied as parameters
to the insmod and
Getting Information About A Kernel Module - modinfo
- In order to get information about a Module (author, supported options),
we may use the modinfo command.
- For example, information about the 'mousedev' Module:
[choo@simey ~]$ /sbin/modinfo mousedev
description: "Input driver to PS/2 or ImPS/2 device driver"
author: "Vojtech Pavlik "
parm: xres int, description "Horizontal screen resolution"
parm: yres int, description "Vertical screen resolution"
- The source code of the Module can also be used to get information about
it. In some cases, there are interesting comments at the top of
the source file.
Standard Kernel Drivers
- Many Drivers come as part of the distribution's Kernel. Use Them.
- These Drivers are stored, as we saw, in the /lib/modules/ directory.
- Sometimes, the Module file name will imply about the type of Hardware
- Often, a search on Google would give the Module's name, assuming we
looked for the chip-set, not for the marketing name of the
- Finally, looking on the web page of the company that manufactures the
product, or the chip-set, might come up with a Driver. If we're lucky,
this Driver is already part of our Kernel, and we don't need to download
What If Our Driver Is Not Compiled?
- Some Drivers might come as part of our Kernel's sources, but still not
be compiled in the distribution's default Kernel.
- We can see this by looking for the Driver in the Kernel source tree...
- ... Or by reading about its existence on the web, or in the Kernel source
- To compile this Driver, we will need to perform a full Kernel compilation
and then compile the Driver.
- Usually, the second time around, we will not need to re-compile the
entire Kernel - just the 2nd Driver.
Originally written by
- We covered the interaction between the Linux Kernel and Processes,
and between the Linux Kernel and Hardware.
- We saw what are Kernel Modules, and how to manipulate them.
- We learned about Device files and their purpose.
- We learned about identifying the Hardware in our computer.