Writing Device Drivers in Linux: a brief tutorial (1)

I recently saw a good guide on Linux kernel entry abroad, so I tried to translate it. Because it is the first time to try translation, and the English level is limited, errors are inevitable. Thank you!

Since there is no time for this, it is certainly impossible to complete the translation, so part of the translation is translated every day. Reprinted, please specify the source and respect others' successful work. Thank you!

Writing System drivers: a simple guide

A Brief Introduction to writing Linux device drivers like a kernel developer

Author: Xavier calbet

2006-04-26

 

Prerequisites:

To be able to develop Linux kernel drivers, it is necessary to have the following knowledge:

L c programming experience: You need to have an in-depth understanding of C language development experience, such as using pointers and bitwise functions.

L microprocessor programming: it is necessary to understand the working principle of a microcomputer: memory addressing and interruption. This content should be familiar to an assembly language programmer.

 

There are several different devices in Linux. For simplicity, this article only describes the character device drivers loaded in the form of modules. The kernel version used is 2.6.x (especially the 2.6.8 kernel under Debian Sarge, which is currently stable In Debian ).

 

User space and kernel space:

When writing device drivers, you must be able to distinguish between "user space" and "kernel space"

L kernel space: Linux (kernel) uses a simple and effective way to manage computer hardware and provides users with a simple and unified interface. Similarly, the kernel, especially its device driver, serves as a bridge between end users or programmers and hardware. Any subprograms or functions (such as module and Device Drivers) that constitute part of the kernel are considered part of the kernel space.

L user space: end user programs, such as UNIX shell or other Gui-based applications (such as kpresenter) are part of the user space. Obviously, these applications need to interact with system hardware. However, they will not do it themselves, but through Kernel support functions.

All of these tables 1 are shown below:

Table 1 user space of an application, kernel space of a module or device driver

User space and kernel space interface functions

The kernel provides some subprograms and functions for the user space. Through these subprograms and functions, the application programmer can interrupt the interaction with the hardware. Generally, in Unix or Linux systems, these session exchanges are completed by Reading and Writing File subroutines or functions. In Unix systems, devices are viewed by files from the user perspective.

On the other hand, in the kernel space, Linux also provides several functions or subroutines to complete the tasks of direct interaction between the underlying layer and hardware, and allows the kernel information to be transmitted to the user space.

In general, each function of a device or file is allowed in the user space, and there is a function equivalent to it in the kernel (these functions can complete the transfer of kernel space information to the user space, and vice versa ). These are all in the following table. At present, this table is still blank. We will fill it up after introducing different device driver concepts.

Events	User Functions	Kernel functions
Load Module
Open Device
Read Device
Write Device
Close deviece
Remove Module

Table Device Driver events and corresponding interaction functions in user space and kernel space