1. Drivers and the Kernel
Chapter 12

2. Chapter 12 - Drivers and the Kernel
Introduction
A UNIX system encompasses essentially three layers of abstraction:
The hardware
The operating system kernel
The user-level programs
The kernel hides the system’s hardware underneath an abstract, high-level programming interface.
It is responsible for implementing many of the facilities that users and user-level programs take for granted
Chapter 12 - Drivers and the Kernel

3. Chapter 12 - Drivers and the Kernel
Introduction
For example, the kernel assembles all of the following UNIX concepts from lower-level hardware features.
Processes (timesharing, protected address spaces
Signals and Semaphores
Virtual Memory (swapping, paging, and mapping)
The filesystem (files, directories, namespace)
Interprocess communication (pipes and network connections)
Chapter 12 - Drivers and the Kernel

4. Chapter 12 - Drivers and the Kernel
Introduction
The kernel contains device drivers that manage its interaction with specific pieces of hardware; the rest of the kernel is, to a large degree, device independent.
The relationship between the kernel and the device drivers is similar to the relationship between user-level processes and the kernel.
The kernel is written mostly in C, with a little assembly language for low level processing.
Chapter 12 - Drivers and the Kernel

5. Chapter 12 - Drivers and the Kernel
1. Kernel Types
Introduction:
All systems allow you to provide the kernel with explicit information about the hardware it should expect to find on your system
Or pretend not to find, as the case may be.
Some kernels can also prospect for devices on their own.
Chapter 12 - Drivers and the Kernel

6. Chapter 12 - Drivers and the Kernel
1. Kernel Types
Solaris:
Solaris uses an almost completely modular kernel and it can load device drivers as needed.
You do not need to tell Solaris ahead of time what hardware is on the system.
When Solaris finds a new device connected to the system, it looks for and loads a corresponding driver module.
Surprisingly, this scheme actually works fairly well most of the time.
Chapter 12 - Drivers and the Kernel

7. Chapter 12 - Drivers and the Kernel
1. Kernel Types
HP-UX:
Like Solaris, HP-UX supports a relatively small and well defined hardware base.
It can usually determine what’s on your system without much hand holding from you.
Chapter 12 - Drivers and the Kernel

8. Chapter 12 - Drivers and the Kernel
1. Kernel Types
FreeBSD:
In general BSD-derived systems must be told explicitly at kernel compilation time what devices might be found on the system.
You must also specify where on the system to find it.
This requirement is often troublesome if you aren’t sure exactly what hardware your system contains.
Chapter 12 - Drivers and the Kernel

9. Chapter 12 - Drivers and the Kernel
1. Kernel Types
Linux:
Linux is a bit of a cross between Solaris and BSD.
Like FreeBSD it is crippled by the PC environment, in which it is difficult to take an accurate inventory of the system’s hardware.
Linux’s module support is limited compared with Solaris, but many of its limitations have been dictated by the restrictions of PC hardware
Chapter 12 - Drivers and the Kernel

10. Chapter 12 - Drivers and the Kernel
1. Kernel Types
This table shows the location of the kernel build directory and the standard name of the installed kernel.
Chapter 12 - Drivers and the Kernel

11. 2. Why Configure the Kernel
When the system is installed, it comes with a generic kernel that’s designed to run on most any hardware.
The generic kernel includes many different device drivers and option packages.
Since the kernel only needs to run on your particular system, it’s a good idea to reconfigure it to get rid of the modules you won’t be using and to turn off the options that don’t interest you.
Chapter 12 - Drivers and the Kernel

12. 2. Why Configure the Kernel
Building a kernel tailored to the system is a good habit to get into.
Your well-tuned kernel configuration, once obtained, can serve as a reference guide for the system’s hardware
Although unused features and drivers might not interfere directly with the operation of the system, they can still consume memory.
Chapter 12 - Drivers and the Kernel

13. 2. Why Configure the Kernel
Another reason to reconfigure the kernel is to add support for new types of devices.
The new drivers have to be integrated into the kernel’s data structures and tables.
Building a kernel is not difficult; it’s just difficult to fix when you break it.
Chapter 12 - Drivers and the Kernel

14. 3. Configuring a Solaris Kernel
At boot time, the Solaris kernel probes the machine for devices and initializes a driver for each device it finds.
It makes extensive use of loadable modules and loads code only for the devices that are actually present (unless forced to do otherwise).
Flaky, nonstandard, or just plain buggy hardware (or Solaris drivers) can turn this creature comfort into a torment.
Chapter 12 - Drivers and the Kernel

15. 3. Configuring a Solaris Kernel
The Solaris kernel area
To make on-demand module loading work correctly, Solaris relies heavily on a particular directory organization.
/kernel - modules common to machines that share an instruction set.
/platform/platform-name/kernel - modules specific to one type of machine (Ultra Enterprise)
/platform/hardware-class-name/kernel - modules specific to one class of hardware (sun4u machines)
/usr/kernel - similar to /kernel
Chapter 12 - Drivers and the Kernel

16. 3. Configuring a Solaris Kernel
Each of those directories can contain several standard subdirectories
Chapter 12 - Drivers and the Kernel

17. 3. Configuring a Solaris Kernel
Configuring the kernel with /etc/system
Solaris’s /etc/system file serves as the master configuration file for the kernel.
Chapter 12 - Drivers and the Kernel

18. 3. Configuring a Solaris Kernel
Debugging a Solaris configuration
Since Solaris makes up its view of the world on the fly, debugging a troubled machine can be frustrating
Fortunately Solaris provides several tools
prtconf - prints the machines general configuration.
sysdef - prtconf on steroids (adds a lot more info)
modinfo - reports information about dynamically loaded modules
Chapter 12 - Drivers and the Kernel

19. 4. Building an HP-UX Kernel
HP-UX takes the older approach of building all of its drivers into one monolithic kernel.
However, HP-UX’s SAM administration tool provides a way to bypass all the nasty configuration files.
You should definitely use SAM the first few times you build an HP-UX kernel.
Chapter 12 - Drivers and the Kernel

20. 5. Configuring a Linux Kernel
Linux kernel configuration has come a long way, but it still feels very primitive compared to most other systems.
The process revolves around the /usr/src/linux/.config file
All of the kernel configuration information is specified in this file, but its format is pretty cryptic.
To save folks from having to mess with the .config file, Linux has several make targets that let you configure the kernel with different targets
Chapter 12 - Drivers and the Kernel

21. 5. Configuring a Linux Kernel
If you are running X Windows, the prettiest configuration is provided by make xconfig.
This command brings up a graphical configuration screen from which you can pick the devices you want added to your kernel (or compiled as a loadable module)
If you are not running X, you can use a curses-based alternative invoked with make menuconfig.
Avoid make config.
Chapter 12 - Drivers and the Kernel

22. 5. Configuring a Linux Kernel
Building the Linux kernel binary
Setting up the appropriate .config file is the most important part of the Linux kernel configuration process, but you must jump through several more hoops to turn that file into a finished kernel.
Chapter 12 - Drivers and the Kernel

23. 5. Configuring a Linux Kernel
Here’s an outline:
cd /usr/src/linux
make xconfig
make dep
make clean
make bzImage
make modules
make modules_install
cp /usr/src/linux/i386/boot/bzImage /boot/vmlinux
cp /usr/src/linux/arch/i386/boot/System.map /boot/System.map
Fix your boot loader (e.g. lilo)
Chapter 12 - Drivers and the Kernel

24. 5. Configuring a Linux Kernel
Tuning your Linux configuration
Linux does provide an extensive kernel-to-userland interface through files in the /proc filesystem.
Several files and directories in /proc let you view and set kernel options at run time.
These files mimic standard UNIX files, but they are really back doors to the kernel.
Chapter 12 - Drivers and the Kernel

25. 6. Building a FreeBSD kernel
Although the examples in this section are specifically from a FreeBSD machine, configuration for NetBSD, OpenBSD, and BSD/OS is similar.
To build a FreeBSD kernel, you first create a configuration file that lists the parameters of the new kernel.
You then run the config command to build a kernel compilation directory as specified in your config file.
The name you give the config file becomes the name of the directory and eventually the kernel.
Chapter 12 - Drivers and the Kernel

26. 6. Building a FreeBSD kernel
The master recipe for building a kernel
The eight steps are:
Audit the system’s hardware
Create and edit the kernel’s configuration files (Sys/i386/conf)
Run the config program from the conf directory
run make depend in the compilation directory
Build the kernel with make
Archive the old kernel and install the new one.
Test and debug the new kernel
Document the new kernel.
Chapter 12 - Drivers and the Kernel

27. Chapter 12 - Drivers and the Kernel
8. Adding Device Drivers
A device driver is a program that manages the system’s interaction with a particular piece of hardware.
The driver translates between the hardware commands understood by the device and the stylized programming interface used by the kernel.
The existence of the device driver layer helps keep UNIX reasonably device independent.
Chapter 12 - Drivers and the Kernel

28. Chapter 12 - Drivers and the Kernel
8. Adding Device Drivers
Device drivers are part of the kernel; they are not user processes.
However a driver can be accessed both from within the kernel and from the user space.
User level access to devices is usually provided through special device files that live in /dev
The kernel transforms operation on these special files into calls to the code of the driver.
It is not at all uncommon to have to add a device driver to your kernel to support a new piece of hardware.
Chapter 12 - Drivers and the Kernel

29. Chapter 12 - Drivers and the Kernel
8. Adding Device Drivers
Device numbers
Many devices have a corresponding file in /dev
The notable exception being network devices
The major device number identifies the driver that the file is associated with.
The minor device number usually identifies which particular instance of a given device type is to be addressed. This is sometime called the unit number.
Chapter 12 - Drivers and the Kernel

30. Chapter 12 - Drivers and the Kernel
8. Adding Device Drivers
You can see the major and minor number of a device file with ls -l
The minor device number is sometimes used by the driver to select a particular set of characteristics of a device.
For example: a single tape drive can have several files in /dev representing it in various configurations of recording density and rewind characteristics.
In essence, the driver is free to interpret the minor device number in whatever way it wants.
Chapter 12 - Drivers and the Kernel

31. Chapter 12 - Drivers and the Kernel
8. Adding Device Drivers
There are actually two types of device files:
block device files, and character device files
A block device is read or written one block at a time
A block is a group of bytes, usually a multiple of 512
A character device can be read or written one byte at a time.
Some devices support access through both block and character device files.
Disks and tapes lead dual lives
Terminals and printers do not.
Chapter 12 - Drivers and the Kernel

32. Chapter 12 - Drivers and the Kernel
8. Adding Device Drivers
Device drivers present a standard interface to the kernel. Each driver has routines for performing some or all of the following functions:
attach, close, dump, ioctl, open, probe, psize, read, receive, reset, select, stop, strategy, timout, transmit, write
It is sometimes convenient to implement an abstraction as a device driver (even when it controls no actual device)
pseudo TTY’s are like this
Chapter 12 - Drivers and the Kernel

33. Chapter 12 - Drivers and the Kernel
8. Adding Device Drivers
Drivers and their configuration files are typically stashed away in a nonobvious location to prevent the uninitiated from mucking with them.
Chapter 12 - Drivers and the Kernel

34. Chapter 12 - Drivers and the Kernel
9. Device Files
By convention device files are kept in /dev
Large systems, especially those with networking and pseudo-terminals, may support hundreds of devices.
Device files are created with the mknod command
mknod filename type major minor
filename is the device file to be created
type is c of b
A shell script called MAKEDEV is sometimes provided to automatically supply default values to mknod
Chapter 12 - Drivers and the Kernel

35. 10. Naming Conventions for Devices
Naming conventions for devices are somewhat random.
They are often holdovers from the way things were done on a DEC PDP-11
For devices that have both block and character identities, the character device name is usually prefaced with the letter r for “raw”
e.g. /dev/da0 vs. /dev/rda0
Chapter 12 - Drivers and the Kernel

36. 10. Naming Conventions for Devices
This table lists some typical names for common devices such as disks and CD-ROM drives.
Chapter 12 - Drivers and the Kernel

37. 11. Loadable Kernel Modules
Loadable kernel modules have come a long way in the last 5 years.
Solaris, Linux, and FreeBSD all support kernel modules although the degree of support varies widely.
Solaris is a very modular kernel, Linux is pretty modular, and FreeBSD barely supports kernel modules at all.
Chapter 12 - Drivers and the Kernel

38. 11. Loadable Kernel Modules
LKM support allows a device driver - or any other kernel service - to be linked into and removed from the kernel while it is running.
This makes the installation of driver much easier, since the kernel binary does not need to be changed.
It also allows the kernel to e smaller because drivers are not loaded unless the are needed.
Although LKMs are convenient, they are not entirely safe.
Any time you load or unload a module, you risk causing a kernel panic.
Chapter 12 - Drivers and the Kernel

39. Chapter 12 - Drivers and the Kernel
12. Recommended Reading
McKusick, Marshall, et al., The Design and Implementation of the 4.4BSD Operating System. Reading MA: Addison Wesley
There is a new version based on FreeBSD coming out.
Beck, Michael, et al., Linux Kernel Internals, second edition. Reading MA: Addison Wesley
Chapter 12 - Drivers and the Kernel

40. Chapter 12 - Drivers and the Kernel