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

* 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 ):o /proc/interrupts – a list of interrupt numbers (IRQs) currently in use by different Drivers.o /proc/ioports – a list of I/O addresses currently in use by Drivers.o /proc/pci – info about PCI Devices.o /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:o hda – first (a) IDE Device (hard disk, CDROM).o hdb3 – 3rd (3) partition of second (b) IDE Device (must be a hard disk. CDROMs have no partitions).o ttyS0 – first serial port (“COM1”).o sda1 – 1st (1) partition of first (a) SCSI Device (hard-disk, an emulated SCSI Device, etc.).o 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.

Listing Loaded Modules With lsmod

In order to see the list of currently loaded Modules, use the lsmod command:

* 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:o pcmcia – PCMCIA Drivers, for laptops.o kernel/net – network-related Modules (firewall, extra protocols support, etc.)o kernel/drivers – Drivers for various types of Hardware (including network Drivers).o kernel/fs – file-systems support (ext3, vfat, etc.)o 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:

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

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:

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

alias eth0 8139too

o 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:

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