Linux Kernel Development

Hemen Kapadia 27 th January, 2007 Linux Kernel Development – Character Device Drivers Basics

Device Driver Overview

Compiling and Booting the Kernel

Module Development

Character Device Driver Development

References

Device Driver Overview

Device Drivers: Starting Point

Scope of Device Drivers

Device Types

Kernel Subsystems

Device Drivers : Starting Point

Linux kernel is a large and complex piece of code.

Kernel newbies are overwhelmed by the complexity.

Device drives provide a gateway to approach the kernel in a less intimidating manner.

Device drivers are written as modules, and compiled independently of the kernel.

Can be plugged to the kernel during runtime depending on requirement of a particular functionality.

Scope of Device Drivers

Device drivers provide a mechanism rather than dictate a policy.

Focus on “what capabilities are to be provided” instead of “how the capabilities will be used”.

For example the floppy driver should only focus on showing the disk as a continuous array of data blocks, it should not focus on checking access permissions etc..

Policy decisions can be made at application level.

However, some policy decisions can be taken.

Device Types

Linux classifies devices into three classes

Character Devices

Can be accessed as a stream of bytes like a file, but unlike files where we can navigate back and forth, character devices are simple data channels that can be accessed sequentially. Example /dev/ttyS0

Block Devices

Devices that usually handle IO operations involving data transfer of one or more whole blocks (usually 512 bytes) are called block devices. Storage devices are usually block devices. Usually have a buffer for requests, to decide on the best way to cater the requests. Ex. /dev/hda

Network Devices

These are special devices that provide an interface for exchanging data with other hosts. Usually this is a hardware device but is can also be a pure software interface like the loopback device. Unlike character and block devices, network device does not have mapping in the file system

Kernel Subsystems

App1 App2 C Library Actual respective hardware System Call Interface Process Mgmt Memory Mgmt Filesys Mgmt Device Ctrl Networking Filesys Types CPU support code CPU/MMU support code Storage Drivers Character Device Drvr Network Device Drvr

Compiling and Booting

Kernel Versioning Scheme

Downloading Source

Kernel Configuration

Kernel Compilation

Kernel Installation and Booting

Kernel Versioning Scheme

Stable releases

A stable release every 1 or 2 months

Examples: 2. 0 .40, 2. 2 .26, 2. 4 .27,

Stable versions have an even second number.

Development versions

Unstable versions used by kernel developers before making a new stable major release

Examples: 2. 3 .42, 2. 5 .74

Development versions have a odd second number.

Downloading Source Code

All steps to be executed as normal user unless specified.

Kernel source code can be downloaded from http:// www.kernel.org .

Source is available as a bzip file (tar.bz2) or a gzip file (tar.gz).

Extract the source (example commands to extract 2.6.15 source)

tar jxvf linux-2.6.15.tar.bz2 (in case of bzip file)

tar zxvf linux-2.6.15.tar.gz (in case of gzip file)

This will create a directory linux-2.6.15 in the current directory

Usually the kernel source is located in /usr/src/linux . Do not use this directory to compile your custom kernel.

Strongly recommended to you use your home directory, so that we can compile the kernel as a normal user and also prevent corruption of any existing kernel source.

Kernel Configuration

Kernel configuration is the process which defines what features are to be included in the kernel and including mechanism.

A feature can be configured to be included into the kernel core (inbuilt), to be compiled as a module (to be inserted at runtime) or not to be included at all.

This generates a file .config in the current directory.

The xconfig , gconfig and menuconfig utilities provide a graphical menu based configuration mechanism, whereas config does this with an interactive console based dialogue.

make oldconfig is used to upgrade the .config file from an earlier kernel release. It will issue warning for obsolete symbols and ask new values for new symbols.

To list all available targets use make help

Kernel Compilation

To compile the kernel and modules issue make

To clean the compilation directory of all the built files use make clean . This will not remove the configuration settings of the kernel.

To clear the configuration settings also issue the command make mrproper .

After a successful build the following files will be generated. All paths are relative to the kernel compilation directory.

vmlinux: The raw kernel image, uncompressed.

arch/<arch-type>/bzImage: Zlib compressed kernel image

System.map: Kernel symbols mapping address

Installation and Booting (as root)

In previous step we have successfully compiled the kernel and the modules. Now we need to install and boot the system.

To install the compiled modules issue make modules_install

This will copy all modules from the kernel compilation directory to /lib/modules/<kernel version number>

Next, we need to create the initial ram disk. This can be done as

mkinitrd –v –f /boot/initrd-<kernel-version>.img <kernel-version>

Next we need to copy .config, bzImage and System.map from kernel build directory to /boot.

cp .config /boot/config-<kernel-version>

cp System.map /boot/System.map-<kernel-version>

cp arch/i386/boot/bzImage /boot/vmlinuz-<kernel-version>

Installation and Booting (contd.)

Now we need to update /boot/grub/grub.conf file so as to enable us to boot the system with your customised kernel.

In case you have lilo as the bootloader, configure /etc/lilo.conf and run lilo.

Restart the system and select your customised kernel in the bootloader menu for the system to boot.

Module Development

Introduction to module development

Module Operations

Compiling and Loading a module

The __init and __exit macros

Licensing and additional information

Developing a simple module

Introduction to Module Development

Extend the functionality of the kernel without a need to reboot the system.

Loaded and unloaded from the kernel on demand. Once loaded they have full access to kernel’s public symbols.

Help in reducing the size of the kernel.

Useful to support incompatible drivers (either load one or the other, but not both).

Useful to deliver binary only drivers without having to rebuild the kernel.

Modules make it easy to develop drivers without rebooting: load, test, unload, rebuild, load...

Modules can also be compiled statically into the kernel.

Module Operations

Modules can be loaded using modprobe or insmod

Inserted modules can be listed using lsmod

Modules can be removed using rmmod .

Licensing and additional information about modules is obtained using modinfo .

Module dependencies can be obtained using depmod –a <kernel-version> .

The module dependencies are stored in /lib/modules/<kernel-version>/modules.dep

The dependencies are automatically computed during kernel build from module exported symbols. The user need not specify any dependencies

Compiling modules is different than compiling user space programs

Compiling modules is now integrated with Kbuild, the kernel build mechanism

Kbuild file lists the objects that are to be compiled as modules against obj-m tag

The Makefile contains the rules to transform the code to a module object

The make syntax for this is (as normal user)

make –C <kernel build dir> -M `pwd` modules

For more information refer Documentation/kbuild/modules.txt in kernel source.

This will create a *.ko file in the working directory.

It can then be installed as (as root user)

/sbin/insmod ./<module-name>.ko

To remove it use command (as root user)

/sbin/rmmod <module-name>

The __init and __exit macros

init_module and cleanup_module names are no longer mandatory.

They can be user defined but need to be specified to the kernel using module_init() and module_exit() macros.

The __init macro causes the init function to be discarded and its memory freed once the init function finishes. This is applicable for built-in modules, and not for loadable modules.

The __exit macro causes the omission of the function when the module is built into the kernel, and like __init , has no effect for loadable modules.

Licensing and additional information.

Mechanism to identify code licensed under the GPL (and other licenses) so people can be warned if the code is non open-source.

Used by kernel developers to identify issues coming from proprietary drivers.

Useful for users to check that their system is 100% free.

Useful for GNU/Linux distributors for their release policy checks.

This is implemented with MODULE_LICENSE() macro. As of now following license idents are recognised :

"GPL" [GNU Public License v2 or later]

"GPL v2" [GNU Public License v2]

"GPL and additional rights" [GNU Public License v2 rights and more]

"Dual BSD/GPL" [GNU Public License v2 or BSD license choice]

"Dual MPL/GPL" [GNU Public License v2 or Mozilla license choice]

"Proprietary" [Non free products]

Licensing and additional information (contd.)

Apart from the licensing information additional information can also be provided using the following macros

MODULE_AUTHOR

MODULE_DESCRIPTION

MODULE_VERSION

MODULE_SUPPORTED_DEVICE

Most are self explanatory, version string is of the format [<epoch>:]<version>[-<extra-version>]

The MODULE_SUPPORTED_DEVICE macro might be used in the future to help automatic configuration of modules, but is currently unused other than for documentation purposes.

Character Device Driver Development

Major and Minor numbers

User Space and Kernel Space

User Space and Kernel Space data exchange.

Character Device Driver Methodology

Structures used for writing device drivers.

Registering a Device

Unregister a Device.

Issues (try_module_get and module_put)

Sample Character Device Driver code.

Major and Minor numbers.

If you issue a “ ls –l /dev ” command you will notice a column of numbers separated by a comma. The first number is called the Major number and the second is called the Minor number. e.g.

crw-rw-rw- 1 root root 1, 3 Nov 26 21:42 /dev/null

The Major number tells which driver is used to access the hardware. Each device driver is allocated a number.

All devices controlled by the same driver have the same Major number.

The Minor number is used by the device driver to distinguish among the various hardware it controls.

To see a list of devices registered on the system and the corresponding major numbers issue “ cat /proc/devices ”

“ mknod ” command is used to create a device file.

Device Types

Devices are divided into two types:

Character Devices

Block Devices

Block devices have a buffer for requests, so they can decide the best order to cater the requests. Storage devices are mostly block devices. Block devices can perform IO operations in chunks of specific size called block. This block size may vary for different devices.

Character devices on the other hand can use as many or as few bytes for IO as they need. Most devices are character devices.

The first character in the output of ls –l command will help us identify if a device is character or block device. In case of character device it is “ c ” whereas for block it is “ b ”.

“ mknod ” command is used to create a device file.

User Space and Kernel Space.

Read buffer Write string read write /dev/foo major/minor User Space Device Driver read handler write handler copy to user copy from user User space needs a device file in /dev to interact with the device through regular file operations (open, read, write etc..) The information of which particular device driver is in charge of device files with a particular major/minor number pair is required by the kernel. Also the kernel would need to have information on which handler functions are to be executed for user space file operations (open, read, write, close) for a given driver

User Space and Kernel space data exchange

Cannot directly use memcpy between an address in user space and an address in Kernel space as

They correspond to completely different address space due to virtual memory.

User space address can be swapped out.

To achieve this we need to use dedicated functions like

put_user()

get_user()

copy_to_user()

copy_from_user()

All these function should return with 0

Any other return value is regarded as an error

Character Device Driver Methodology.

To write a character device driver following operations need to be done

Register one or a number of device numbers (major/minor) depending on the number of devices to be managed by the driver.

Register the handler functions that will be called when the user space programs access the device file.

This is usually done during module initialization.

Device numbers are assigned by Torben Mathiasen in the kernel development community. Check Documentation/devices.txt in the kernel source directory to find one not yet assigned. However it is a bad practice as it can get assigned in the future.

Best is to get them registered dynamically, but in that case you cannot make the device file in advance. However this does not cause a hindrance as there are ways to get the dynamically assigned major number.

file_operations : used to store pointers to the functions that serve as operation handlers for various user space file operations like open, read etc…

Not all fields are required. A minimalist set of operations can be achieved by this

struct file_operations fops = { .read = device_read, .write = device_write, .open = device_open, .release = device_release };

struct file : used to represent each open device in the kernel

It is created by the kernel in the open system call.

It is a kernel level structure and never appears at the user space. It should not be confused with FILE, which is a defined by glibc and never appears at kernel level.

It is usually an argument in the function handlers defined in file_operations structure explained previously. For example:

ssize_t (*read) ( struct file *, /* Open file descriptor */ char *, /* Userspace buffer to fill up */ size_t, /* Size of the userspace buffer */ loff_t *); /* Offset in the open file */ Called when userspace reads from the device file.

Registering a character device.

This is synonymous to assigning a major number to the device during module initialization.

register_chrdev() is used to assign a major number to the device file.

In case major is passed as 0, then it dynamically allocates a major number and returns with the same.

int register_chrdev( unsigned int major, //req. major number, 0 if dynamic const char *name, //name as in /proc/devices struct file_operations *fops); // operation handlers

Unregister a character device.

unregister_chrdev() is used to remove a character device.

We need to pass the device major number and the device name as parameters to this kernel call.

int unregister_chrdev( unsigned int major, // device major number const char *name); //name as in /proc/devices

Issues (try_module_get and module_put).

Cannot allow module to be removed if the corresponding device file in /dev is being accessed by a process.

Removing the module and a subsequent access from user space will cause a call to the memory location where the corresponding handler function was located. The result is unpredictable in this case.