1. Overview
I have read Linux Device Drivers 3 (photocopy) (ldd3 for short) and I have forgotten about it. So I want to take a note of what I have read before, and focus on the comments and understanding of the Code. I am also a beginner in Linux kernel, so I will introduce every detail in the learning-driven process step by step. It is hoped that these blogs will help others, like me, find new entry in the Linux driver and kernel learning field while consolidating their knowledge.
This blog is the beginning of a series of blogs. It mainly introduces the concepts related to the Linux device driver and the establishment of the driver environment.
2. Introduction to Linux drivers
Before getting started with the driver, I heard from my colleagues that he will do driver development in the future, because the driver is at the bottom layer and the technology update is slow, in this way, he does not need to follow popular technologies all day long. At that time, I felt that the driver was a high technology and I was determined to learn the underlying things. Later, my classmate went to Huawei and did not know if he was driving the program. Anyway, I decided to learn about the Linux kernel.
Simply put, a driver is the kernel code used to manage the hardware. The essence of a driver is kernel code, which is used to support upper-layer applications. After learning the driver, I realized how the upper-layer applications work. The driver can exist independently in the form of a module and be loaded into the kernel as needed. It can also be compiled into the kernel and used directly. The two methods have their own advantages and disadvantages. The modular driver makes the kernel smaller, and the built-in driver does not need to load the required modules every time the system is started. Generally, if a module is frequently used, we recommend that you compile it into the kernel. However, modularity has been deeply rooted in the hearts of the people, so the driver introduced in this book ldd3 is mainly modular.
Drivers can be divided into three categories: character device drivers, block device drivers, and network drivers.
Character device drivers are the most common types of drivers. For example, writing a driver to control LEDs is a character device driver. Like a file, these drivers are accessed through a node in the file system (under the/dev directory. The operations implemented by the character device driver should include open, close, read, and write. The operations on the device are based on byte streams, just like operating a file (maybe no lseek operation ).
A block device driver is usually related to a storage device. A file system, such as a hard disk, can be installed on a block device. In most Unix systems, block device-driven operations are not based on byte streams, but on blocks. A block is generally 512 bytes. However, in Linux, the block driver can transmit any data at a time, which is exactly the same as the character device. In addition, the application accesses the block device driver through the file system node in/dev.
Network devices will not be introduced here.
3. Build a Development Environment
You can use the following command to copy the ldd3 code from the GIT Repository:
git clone https://github.com/duxing2007/ldd3-examples-3.x
After cloning the repository to a local directory, go to the repository directory and run the make command to compile the repository. This repository contains Sample Code introduced in each chapter of ldd3 for reference. The usage of specific modules in the repository and errors during compilation will be described in future blogs.
Device Drivers-ldd3 Reading Notes