Sixth. First Linux driver: Count the number of words

One, what is the Linux driver exactly what is a thing:

1, actually the Linux drive and the common Linux API does not have the essential difference, only uses the Linux drive Way and uses the Linux API the way is different;

2. The Linux system maps each driver into a single file. These files are called device files or drive files and are saved in the/dev directory. This design concept makes interacting with Linux drivers as easy as interacting with ordinary files, and easier than accessing the Linux API. Since most Linux drivers have their corresponding device files, exchanging data with the Linux driver becomes the exchange of data with the device files.

3, to write Linux drivers also need more advanced features, to achieve this process requires that the Linux driver can respond to the data passed by the application. This is a Linux-driven event, although there is no concept of events in C, but there are concepts similar to events, called callback functions. Therefore, the most important step in writing a Linux driver is to write a callback function, otherwise data that interacts with the device file will not be processed.

4. The relationship between application software, device files, drivers, hardware:

Ii. steps to write a Linux driver

1th Step: Build Linux driver skeleton (load and unload Linux drivers)

Any type of program has a basic structure. Linux drivers are no exception.

The Linux kernel needs to load the driver first when it uses the driver. Some initialization work is required during the loading process, such as setting up a device file, allocating memory address space, and so on. When the Linux system exits, the Linux driver needs to be uninstalled, and the resources used by Linux drivers are freed during the uninstallation process, such as deleting the device files, freeing the memory address space, and so on.

In the Linux driver, you need to provide two functions to handle the operation of the driver initialization and exit separately. The two functions are specified with Module_init () and Module_exit () macros, respectively. Linux drivers typically need to specify both functions, so a C program file containing two macros of two functions can also be seen as a Linux-powered skeleton.

2nd step: Registering and unregistering device files

Any Linux driver requires a device file, or the application will not be able to interact with the driver.

The role of establishing a device file is generally done in the 1th step of writing a function that handles the initialization of Linux. Deleting a device file is generally done in the 1th step of processing the Linux exit function, and you can create and remove device files using the Misc_register and Misc_deregister functions, respectively.

3rd Step: Specify driver-related information

The driver is self-describing. You can get the author name of the driver, the Open source protocol used, the alias, the driver description and other information through the Modinfo command. This information needs to be specified in the driver source code.

The Module_author, Module_license, Module_alias, Module_description, and other macros can be used to specify driver-related information.

4th step: Specify the callback function

Linux drivers contain a variety of actions, which can also be called events. For example, when writing data to a device file, the write time is triggered, and the Linux system invokes the write callback function of the corresponding driver, which triggers a "read" time when the data is read from the device file, and the Linux system invokes the read callback function for the corresponding driver.

A driver does not necessarily specify all of the callback functions. The callback function is registered through the relevant mechanism. For example, a callback function associated with a device file is registered through the Misc_register function.

5th step: Writing Business logic

This step is a core part of the Linux drive. There is no point in having a Linux driver with a skeleton and a callback function. Any full Linux driver will do some work related to its functionality, such as printer drivers sending print instructions to the printer. The COM driver interacts with data based on the rate of transfer. The specific business logic is related to the function of the driver.

The business logic may consist of multiple functions, multiple files, or even multiple Linux driver modules. It depends on the actual situation.

6th step: Writing the Makefile file

The compilation rules for the Linux kernel source code are defined by the makefile file. Therefore, writing a new Linux driver must have a makefile file.

7th step: Compiling Linux drivers

Linux drivers can be compiled directly into the kernel or separately as modules.

8th step: Install and uninstall Linux drivers

If the Linux driver is compiled into the kernel, the driver will automatically load as soon as Linux uses the kernel.

If the Linux driver exists separately in the module, you need to load the Linux driver module with the Insmod or Modprobe command, and use the Rmmod command to uninstall the Linux driver module.

Third, the first Linux driver: Count the number of words

1. Preparation before writing Linux drivers

(1) First create the directory where the Linux driver is stored

Command: Mkdir–p/root/drivers/ch06/wprd_count

(2) Create a drive source code file

Command: Echo ' > word_count.c

(3) Writing makefile files

Command: Echo ' obj-m: = WORD_COUNT.O ' > Makefile

Obj-m means that Linux drivers are compiled as modules (. ko files) and obj-y means that Linux drivers are compiled into the Linux kernel;

Obj-m or obj-y need to use ": =" assignment. If the value of Obj-m or obj-y is WORD_COUNT.O, the make command compiles the word_count.c or WORD_COUNT.S files in the Linux driver source directory into WORD_COUNT.O files. If you use OBJ-M,WORD_COUNT.O, you will be connected to the Word_count.ko file and then load Word_count.ko using the Insmod or modprobe command, if you use Obj_y,word_ The COUNT.O will be connected to the BUILT_IN.O file and will eventually be connected to the kernel. Where BUILT_IN.O is the intermediate target file generated by the. o file that connects the same class of programs. For example, all character device drivers will eventually generate a BUILT_IN.O file.

If the Linux driver relies on other programs, such as PROCESS.C, DATA.C, you need to write the makefile file as follows:

Obj-m: = WORD_COUNT.O

Word_count-y: = PROCESS.O DATA.O

2. Writing the Linux driver framework

The skeleton section is primarily the initialization and exit functions of the Linux driver.

Code:

The PRINTK () function is used to output log information similar to the printf () usage. Why not use printf ()? Here are some questions about what the Linux kernel program can call and what not to call. The Linux system divides the memory into user space and kernel space, and the programs of the two spaces are not directly accessible. printf () runs in user space, PRINTK () runs in kernel space. Therefore, Linux drivers that are part of the kernel program do not have direct access to printf (), and even if the stdio.h header file is included, errors that are not found in the Stdio.h file are thrown when the Linux driver is compiled.

A program running in user space cannot call PRINTK () directly.

is not the user space and kernel space between the program can not interact? The answer is no, otherwise the two pieces of memory become an island. There are many ways to interact between programs running in these two pieces of memory. Where the device files are a major form of interaction. If a user-space program accesses the kernel space, a driver can access the kernel space, and then the user-space program interacts with the driver through the device file.

Linux drivers do not have direct access to programs running in user space, and many functions are implemented on their own. For example, in C, it is common to use malloc () to dynamically allocate memory space, which is not available in Linux drivers. So how do you dynamically allocate memory space in a Linux driver? It's easy to solve a similar problem. Since the Linux driver cannot directly invoke functions running in user space, it is necessary to provide alternatives in the Linux kernel. In the <linux kernel source code >/include directory contains a large number of C language header files, the functions defined in these header files, macros and other resources are running in the user space of the program's replacement. The header file corresponding to the function library running in the user space is in the/usr/include directory.

To compile the Linux driver source code:

Make–c/usr/src/linux-headers-3.0.0-15-generic M=/root/driver/ch06/word_count

When testing Linux drivers, it is not necessarily done on Android devices. Because the Android system and Ubuntu Linux and other Linux distributions are based on the Linux kernel. Most Linux drivers can be tested on Ubuntu Linux or other Linux distributions and then re-compiled into an arm-based target file with the cross-compiler and then installed on Android to work properly.

Because compiling the Linux kernel source code requires the use of the Linux kernel header files. In order to test the driver on Ubuntu Linux, you need to specify the directory (/usr/src/linux-headers-3.0.0-15-generic) of the Linux kernel header file using the-C command-line parameter. Where the Linux-headers-3.0.0-15-generic directory is the Linux kernel source code directory, in which only the include subdirectory has the actual header file, the other directory only makefile and some other configuration files, does not contain the Linux kernel source code. This directory is provided for the development of the current Linux kernel version of the driver and other kernel programs (because the target files generated when compiling Linux drivers only need the header file, in the target file link as long as there is a relevant target file, do not need source code files). If you compile the Linux driver in a modular manner, you need to specify the directory where the driver is located (m=/root/drivers/ch06/word_count).

Driver-related common commands:

(1) Install Linux drivers

Insmod Word_count.ko

(2) See if Word_count is installed successfully

Lsmod | grep word_count

(3) Uninstalling Linux Drivers

Rmmod Word_count

(4) Viewing log information from Linux-driven output

DMESG | grep Word_count | Tail–n 2

DMESG is actually the log information read from/var/log/messages (Ubuntu Linux10.04) or/var/log/syslog (Ubuntu Linux11.10) files, Therefore, you can also use the following command to get the log information from the Linux driver output.

# Cat/var/log/syslog | grep Word_count | Tail–n 2

3, specify the information related to the drive

A complete Linux driver will specify these driver-related information.

Module Module_author ()

Module Description: Module_description ()

Module alias: Module_alias ()

Open Source Agreement: Module_license ()

View driver information: Modinfo Word_count.ko

Depends indicates the current driver module dependency

Vermagic indicates which Linux kernel version the current Linux drive module is compiled under

4. Registration and cancellation of equipment files

Device files are different from normal files and cannot be established using IO functions, you need to use Misc_register () to set up device files and use Misc_deregister () to unregister (remove) device files.

It is generally necessary to set up a device file when initializing Linux drivers and delete the device files when uninstalling Linux drivers. The device file also requires a struct (miscdevice) to describe the information associated with it.

The MISCDEVICE structure has an important amount member variable FoPs, which describes the device files in various function pointers that can trigger events. The data type of the member variable is also a struct file_operations.

The device file is described by the main device number and the secondary device number, and only the secondary device number can be set using Misc_register (). The master device number is set to 10 uniformly. The device with the main device Number 10 is a simple character device with common features in the Linux system. This type of device is called a misc device.

The value of the Miscdevice.name variable is the name of the device file.

Although multiple callback function pointer variables are defined in the file_operations struct, it is only necessary to initialize the File_operations.owner variable if it is not required. If the value of the variable is a module struct, the file_operations can be applied to these driver modules specified by the module. If the value of the owner variable is this_module, the file_operations is applied only to the current driver module.

If the device file is successfully registered, Misc_register () returns an integer other than 0, and returns 0 if the device file fails to register.

All functions and variables are declared static. This is because in the C language, with static declarations of functions, variables and other resources, the system will place these functions and variables in a separate area of memory until the program exits completely, otherwise these resources will not be freed. Once the Linux driver is mounted, the drive will always reside in memory, unless it is manually uninstalled or shut down, so these functions and variable resources remain in memory. In other words, multiple calls to these resources are not carried out in the compression stack, the stack operation, to improve the efficiency of the drive operation.

Shows which main devices and main device numbers are in the current system:

Cat/proc/devices

5. Specifying a callback function

It makes sense to interact with the user-space application and the kernel-space driver. The most common way to interact is to read and write device files.

Sixth. First Linux driver: Count the number of words