Drivers and the Kernel

Drivers and the Kernel Chapter 12

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Chapter 12 - Drivers and the Kernel

Drivers and the Kernel