Summary: Chapter 1 Introduction to device drivers
Chapter 2 Construction and Operation Module
When talking about the driver, you have to start with two terms: kernel space and user space. The user space is the space where your applications run. The kernel space is worth the space where the operating system kernel runs. The user space cannot directly reference or operate the data in the kernel space, and the kernel space cannot directly reference the data in the user space. The operating system kernel manages the entire system resources, including hardware resources. Therefore, the user space cannot directly access hardware resources. The driver provides interfaces for users to access specific hardware resources. To access hardware resources, a user space only needs to call the interfaces provided by the driver. The driver completely blocks internal operations. Therefore, the user space indirectly accesses hardware resources through the special kernel of the driver layer.
The driver is used to provide a mechanism, that is, what functions are required, rather than policies, and policies: how to use these functions. The provision mechanism is the task of the driver, and the policy is the task to be completed by the application. Because different environments have different ways to access the hardware, as the driver writer, we should try our best to make the driver fall short of the policy. When writing the driver, programmers should also pay special attention to it, write the kernel code to access the hardware. do not impose any specific policies on users. Because different users have different requirements.
Kernel functions include process management, memory management, file system, device control, and network functions. All device control operations are completed by the Code related to the controlled device. This code is called a driver, which fully indicates that the driver is part of the kernel.
Since the driver is a part of the kernel, the header file of the kernel is required for writing the driver. For Linux 2.6 kernel drivers, the kernel source code tree is also required. So before writing the driver, you need to figure out that the driver you write is actually writing the kernel, so all the header files used in the program are kernel.
Run the following command to view the path of the kernel source code tree:
# Cd/lib/modules/$ (uname-R)/build/<br/> # pwd
Now write a simple helloworld program to illustrate
# Include <Linux/init. h> <br/> # include <Linux/module. h> <br/> module_license ("dual MPL/GPL"); <br/> static int hello_init (void) <br/>{< br/> printk (kern_alert "Hello, world/N"); <br/> return 0; <br/>}< br/> static void hello_exit (void) <br/>{< br/> printk (kern_alert "Goodbye cruel world/N "); <br/>}< br/> module_init (hello_init); <br/> module_exit (hello_exit );
The contents of makefile are as follows:
OBJ-M = Hello. O <br/> kerneldir? =/Lib/modules/$ (uname-R)/build
Makefile code explanation:
OBJ-M is required by the kernel. The driver's final hello. Ko depends on the hello. o file.
The following is the kernel tree. If the target platform is not the current platform, you only need to change the kerneldir path.
In addition, once the driver is registered in the kernel, other programs can use the device, do not register the driver in the kernel before the internal Initialization is complete. When the driver fails, we should log out of the driver from the kernel.
Copyright statement:
Reprinted Article please indicate the original source http://blog.csdn.net/feiyinzilgd/archive/2010/02/07/5297188.aspx
Contact tan Haiyan or go to tan Haiyan's personal homepage to leave a message.