Introduction

• Linux is a Kernel that comes with built-in Drivers for many types of Hardware.
• 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 manner.
• 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:

Hardware Diagnostics

• 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).

Example output:

[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)

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 query.

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 cat <file>):
  • /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.

Device files

• Represent Hardware Devices to User-Mode applications.
• Look like normal files at first glance.
• Do not contain any data - they are used for communications only.
• In 'ls -l', the first letter is either 'c' or 'b', depending on the Device type (will be explained later).
• Have a major number, describing the type of the Device.
• Have a minor number, describing the instance of the Device (allows several Devices of the same type).
• Look like this:

  [choo@simey ~]$ ls -l /dev/hda
  brw-rw----    1 root     disk       3,   0 Apr 11  2002 /dev/hda
  [choo@simey ~]$ ls -l /dev/ttyS1
  crw-rw----    1 root     uucp       4,  65 Apr 11  2002 /dev/ttyS1
       

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 Device, etc.).
  • 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 cards.
• 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.

Kernel Modules

• 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 lsmod command:

[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 Drivers).
  • kernel/fs - file-systems support (ext3, vfat, etc.)
  • 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

• Module loading and unloading may only be performed by root.
• To load a Kernel Module, use the insmod command:

  [root@simey ~]# insmod eeprom
  Using /lib/modules/2.4.18-17.7.x/kernel/drivers/sensors/eeprom.o
       

  Check with lsmod that the Module was indeed loaded.
• To un-load a Kernel Module, use the rmmod command:

  [root@simey ~]# rmmod eeprom
       

  Check with lsmod that the Module was indeed un-loaded.

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
           /lib/modules/2.4.18-17.7.x/kernel/arch/i386/kernel/longhaul.o
  depmod: *** Unresolved symbols in
           /lib/modules/2.4.18-17.7.x/kernel/arch/i386/kernel/p4-clockmod.o
  depmod: *** Unresolved symbols in
           /lib/modules/2.4.18-17.7.x/kernel/arch/i386/kernel/speedstep.o
       

• In order to have the system take care of these loading dependencies automatically, load a Module using the modprobe command:

  [root@simey ~]# modprobe lm78
       

  or, for a more verbose output:

  [root@simey ~]# modprobe -v lm78
  /sbin/insmod /lib/modules/2.4.18-17.7.x/kernel/drivers/i2c/i2c-core.o
  Using /lib/modules/2.4.18-17.7.x/kernel/drivers/i2c/i2c-core.o
  Symbol version prefix ''
  /sbin/insmod /lib/modules/2.4.18-17.7.x/kernel/drivers/i2c/i2c-proc.o
  Using /lib/modules/2.4.18-17.7.x/kernel/drivers/i2c/i2c-proc.o
  /sbin/insmod /lib/modules/2.4.18-17.7.x/kernel/drivers/sensors/lm78.o
  Using /lib/modules/2.4.18-17.7.x/kernel/drivers/sensors/lm78.o
       

The /etc/modules.conf file

• Contains 'default' parameters for Modules we use often (e.g. network Drivers, sound cards, etc.)
• commonly used lines:
  • alias - specifies that a given Module (Driver) should be used for a given Hardware Device. example:

              alias eth0 8139too
              

  • options - specifies options to supply to a given Module, when it is loaded. example:

              options sb io=0x220 irq=5 dma=1 dma16=0 mpu_io=0x310
              

• Note: module options may also be supplied as parameters to the insmod and modprobe commands.

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
  filename:    /lib/modules/2.4.18-17.7.x/kernel/drivers/input/mousedev.o
  description: "Input driver to PS/2 or ImPS/2 device driver"
  author:      "Vojtech Pavlik "
  license:     "GPL"
  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 it supports.
• 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 Hardware.
• 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 it.

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 documentation (/usr/src/linux/Documentation).
• 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.

Summary

• 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.

Originally written by guy keren