Turn: How to Learn Linux device drivers in the face of constantly upgrading the kernel

Many Linux application developers and Linux Device Driver developers are excited and excited in the face of constantly upgrading linux kernels, GNU development tools, and various graphic libraries in Linux environments. I am excited that new software and tools provide me with more powerful functions. It is very tedious to adapt to the features of new software and build a new environment. This article will discuss how to learn Linux device drivers in the following three aspects ".

Status Quo of kernel development and its impact on technicians
Currently, Linux mainly maintains kernel versions 2.4 and 2.6. In http://www.kernel.org/
You can download the latest 2.6 kernel linux-2.6.31 and the latest 2.4 kernel linux-2.4.37 from the website. The stable version is basically 1 ~ Updated on July 22, March, for example, 2.6.22 to 2.6.23. Upgrade version every 1 ~ Update once every two weeks, for example, 2.6.23.1 to 2.6.23.2.

Because the kernel of a higher version is not fully compatible with the kernel of a lower version, kernel upgrade has a certain impact on the technical staff engaged in Linux development, especially for beginners of Linux.
The kernel upgrade has little impact on those who are engaged in Linux application development, because system calls are basically compatible. Driver developers are the most influential ones. Each kernel update may change the usage of many kernel functions. Among them, there are functions provided by the kernel itself and functions provided by the hardware platform code. The latter changes more frequently. This makes kernel drivers beginners confused, because when they write drivers based on classic books such as Alessandro's Linux device driver program, failed to compile on your Linux platform, or failed to run normally. Your friend will tell you that the kernel you use is inconsistent with the one in the book. What should we do?

I want to explain this question from two aspects: how to write the Linux Device Driver and how to cope with the constantly upgrading kernel.
How to Write a Linux Device Driver
Linux device drivers are part of the Linux kernel and are used to encapsulate hardware details and provide standard interfaces for the upper layer. In order to be able to write out high-quality drivers, engineers must have the following knowledge:

Familiar with processor performance
For example, the system structure, assembly language, working mode, and Exception Handling of the processor are important for beginners :***. That is to say, if you are not familiar with the driver writing method, you can
Don't focus on this item first, because it may affect your interest in device drivers because it is boring and abstract.
As you get familiar with the driver writing, you will naturally be aware of the importance of this item.
Measure the test taker's knowledge about the working principle and communication protocol of the driver.
Such as: Serial controller, graphics card controller, hardware codec, memory card controller, I2C communication, SPI communication, USB communication, sdio communication, I2S communication, PCI communication, etc.
The importance of this item should be needless to say. The premise of writing a device driver is to know how the device operates. But it doesn't mean that drivers can be driven only after you get familiar with the operation methods of all devices. You only need to know the hardware you want to drive. All of these items are important to beginners :*****.

Measure the test taker's knowledge about hardware control methods.
For example, interrupt, round-robin, and DMA, a hardware controller usually has multiple control methods. You need to choose a proper operation method based on the system performance requirements.
This item is important for beginners :****. In the beginner stage, functions are implemented. The master sequence should be: round-> interrupt-> DMA. With the deepening of learning, we need to consider the performance requirements of the system and adopt appropriate methods.

Good GNU
C Programming Basics
For example, the pointer, struct, memory operation, linked list, queue, stack, C, and assembly mixed programming in C language.
These programming syntaxes are the basis for writing device drivers.
This item is important to beginners and beginners :*****.
Good Linux operating system concepts
Such as multi-process, multi-thread, process scheduling, process preemption, process context, virtual memory, atomic operations, blocking, sleep, synchronization, and other concepts and their relationships.
The use of these concepts and methods in device drivers is the biggest difference between Linux Device Drivers and single-chip programming. Only by understanding them can we Compile High-Quality drivers.
This item is important for beginners :***. At first, we can gradually improve our own drivers for the purpose of implementing functions.
Measure the test taker's knowledge about the interface for writing device drivers in Linux kernel.
For example, the cdev of the character device, the gendisk of the block device, and the net_device of the network device, and fb_info of framebuffer device based on these basic interfaces, mtd_info of MTD device, tty_driver of tty device, USB _ Driver of USB device, mmc_host of MMC device, etc.

The Linux Kernel provides standard interfaces for device drivers. The driver writer does not need to be proficient in all the parts of the kernel, but only needs to specify the interfaces left for us by the kernel and implement this interface. The kernel outbound interface adopts the object-oriented approach, that is, the target device is regarded as an object, and a struct is usually used to describe this object. The task of the driver engineer is to implement this object. This struct contains the properties (represented by variables) and operation methods (represented by function pointers) of the device ). For example, the cdev of a character device
Struct cdev {
Struct kobject kobj;
Struct module * owner;
Const struct file_operations * OPS; // a combination of operation methods. Other items are attributes.
Struct list_head list;
Dev_t dev;
Unsigned int count;
};
This item is important for beginners :****. The initial stage can be dominated by imitation, that is, some fixed templates can be applied.
How to deal with the constantly upgraded Kernel
The main impact of kernel upgrades on drivers is: (1) Changes in driver interface definitions (2) Changes in kernel function names, parameters, header files, and macro definitions (3) platform code changes to some functions encapsulated in hardware operations (4) Impact of device models. The following describes how to deal with these problems:

Changes in Driver Interface Definition
For example, the registration interface of the character device driver in the 2.4 kernel is
Int register_chrdev (unsigned int major, const char * Name, struct file_operations * FoPs)
This method is not recommended in the 2.6 kernel, but changed:
Int cdev_add (struct cdev * P, dev_t Dev, unsigned count)
For example, the net_device structure member of the NIC interface in kernel 2.6.27 and the net_device structure member of earlier versions have also changed.
The changes brought about by the definition and registration of this interface do not occur frequently. Solution: refer to the Code in the kernel. This interface definition and registration method can be easily found in the kernel. For example, for the registration method and interface definition of the character device driver, refer to many instances in the kernel driver/Char/directory.

Changes in kernel function names, parameters, header files, and macro definitions
For example, the format and parameters of the interrupt registration function are different between kernel 2.4, kernel 2.6, and kernel later versions.
In 2.6.8, the interrupt registration function is defined:
Int request_irq (unsigned int IRQ,Irqreturn_t (* Handler) (INT, void *, struct pt_regs *), unsigned long irq_flags,Const char * devname, void * dev_id)
Irq_flags has the following values or combinations:
Sa_interrupt, sa_sample_random, and sa_shirq
In 2.6.26, the interrupt registration function is defined:
Int request_irq (unsigned int IRQ,Irq_handler_t handler, unsigned long irqflags,Const char * devname, void * dev_id)
Typedef irqreturn_t (* irq_handler_t) (INT, void *);
Irq_flags has the following values: (corresponding to 2.6.8)
Ir1__disabled, ir1__sample_random, ir1__shared

When these problems occur, the compiler will give us a clear error prompt during compilation. Based on these prompts, you can determine whether the header is missing or whether the function parameter definition is incorrect. The best way to solve the problem is to find information in your target kernel. In this case, you can find the problem by searching. For example, you can search for request_irq in the new kernel to see how the driver in the new kernel uses it. This method is very effective.

Platform code changes to some functions encapsulated in hardware operations
In the kernel, the hardware platform-related code changes frequently during kernel update. It is also closely related to our device drivers. Therefore, you must be familiar with the structure of your platform code before writing device drivers for a new kernel. Sometimes, although the platform provides the interface functions required by the kernel, the functions used are not complete. The following is an example to illustrate the impact of platform code updates on device drivers.

For example, in the linux-2.6.8 kernel, call set_irq_type (irq_eint0, irqt_falling); To set the irq_eint0 interrupt Trigger Signal type of S3C2410, you will find no effect. Tracking code discovery the kernel's set_irq_type function requires the platform to provide an implementation function for the hardware platform

Static struct irqchip jx_irqext_chip = {
. Mask = maid,
. Unmask = maid,
. ACK = maid,
. Type = maid
};
Cloud_irqext_typeIs the implementation function required by the Linux kernel.,However, the implementation of initi_irqext_type in 2.6.8 is as follows:

Static int jx_irqext_type (unsigned int IRQ, unsigned int type)
{
Irqdbf ("Maid: called for IRQ % d, type % d \ n", IRQ, type );
Return 0;
}
It was not implemented. In a later version of kernel, such as 2.6.26, this function is implemented. So be careful. When the platform functions are not good, check the cause or directly operate the hardware register to achieve the goal.

2.6 influence of kernel device model on driver
Writing a device driver in the 2.6 kernel is very different from writing a device driver in the 2.4 kernel. It is a device model that is more complex and hard to understand than the structure of the device driver. You can ignore the device model when learning the driver, but you will find that the driver code in the kernel is basically integrated into the device model. So many times you have to face the reality, you still need to understand it, and its registration method will also change with the kernel upgrade. The best way to solve this problem is to refer to the target kernel driver code.

Summary:
When learning about device drivers, select a popular kernel version and hardware platform. Do not rush to catch up with the latest trends. In this way, you will find a lot of network resources, so you will not feel alone. I think this process should be less than one year. After this process, try to port the driver you have written to each target platform. Some of the above suggestions and solutions are my experience and are for your reference only.

 

Original article: http://www.eechina.com/thread-1729-1-1.html