For many Linux enthusiasts who are interested in the kernel but have no choice, this article aims to introduce a way to understand the Linux kernel source, rather than explain the complex kernel mechanism of Linux;
1. File organization of core source programs:
1. Linux kernel sources are usually installed under /usr/src/linux, and it has a very simple numbering convention: any even core (eg 2.0.30) is a stable core, and any odd core (eg 2.1.42) is a core of development. This article is based on stable 2.2.5 source code, and the second part of the implementation platform is Redhat Linux 6.0. 2. The files of the core source are organized in a tree structure. At the top of the source tree you will see directories like this: • The Arch :arch subdirectory contains all the core code related to the architecture. Each of its subdirectories represents a supported architecture, such as i386 is a subdirectory of the intel cpu and its compatible architecture. PCs are generally based on this directory; ● Include: include subdirectories include most of the header files needed to compile the kernel. The platform-independent header files are in the include/linux subdirectory, the intel cpu-related header files are in the include/asm-i386 subdirectory, and the include/scsi directory is the header file directory for the scsi device; ● Init: The directory contains the core initialization code (note: not the system's boot code), contains two files main.c and Version.c, which is a very good starting point for how the core works. Mm: This directory includes all memory management code independent of the cpu architecture, such as page storage management memory allocation and release; and the architecture-related memory management code is located in arch/*/mm/, such as arch/I386/mm/Fault.c ●Kernel: The main core code, the files in this directory implement the kernel functions of most Linux systems, the most important file is sched.c; likewise, the code related to the architecture is Arch/*/kernel; ●Drivers: Place all device drivers for the system; each driver occupies a subdirectory: for example, block device driver under /block, such as ide(ide.c). If you want to see how all devices that might contain a file system are initialized, you can look at device_setup() in drivers/block/genhd.c. It not only initializes the hard disk, but also initializes the network, because the network needs to be installed when installing the nfs file system: eg, Lib places the core library code; Net, core and network related code; Ipc, this directory contains the core interprocess communication code Fs , all file system code and various types of file operation code, each of its subdirectories supports a file system, such as fat and ext2; Scripts, this directory contains script files for configuring the core. Generally, in each directory, there is a .depend file and a Makefile. These two files are auxiliary files used at compile time. Read these two files carefully to understand the connection and dependencies of each file. Very helpful; moreover, there are also Readme files in some directories, it is a description of the files in the directory, it is also conducive to our understanding of the kernel source; II. Interpretation of actual combat: Add a system call to your kernel
Although Linux kernel source code is organized in a tree structure very reasonable and scientific, the functions associated files are placed in the same subdirectory, which makes the program more readability. However, the Linux kernel source code is too large and very complicated. Even with a very reasonable file organization method, there are still many associations between files in different directories. Some of the core code analysis will usually look at other files. Related files, and maybe these files are not in the same subdirectory. The sheer complexity of the system and the intricacies of the links between the documents may be the main reason many people are afraid of it. Of course, the rewards of this daunting work are also very fascinating: you can not only learn a lot of the underlying knowledge of the computer (as guided by the system below), but also the whole operation. The subtlety of the system architecture and the cleverness of the algorithm when solving a specific detail problem; and more importantly: in the process of analyzing the source code, you will be specialized little by little, even as long as After analyzing one tenth of the code, you will have a deep understanding of what kind of code is written by a professional programmer, what kind of code is written by an amateur. In order to make readers better understand this feature, the following gives a concrete example of kernel analysis. I hope that through this example, readers can have some specific understanding of the organization of Linux kernel, and readers can also learn some Kernel analysis method. The following is an analysis example: A, operating platform:
Hardware: cpu intel Pentium II; Software: Redhat Linux 6.0; kernel version 2.2.5 B, related kernel source code analysis:
1 . System booting and initialization: There are several ways to boot a Linux system: Commonly there are Lilo, Loadin boot and Linux bootstrapping (bootsect-loader), while the latter corresponds to the source program arch/i386/boot/bootsect. S, it is a real-mode assembler, limited to the length of the analysis here; no matter which boot method, the last jump to arch /i386 /Kernel /setup.S, setup.S is mainly in the runtime mode Initialization, in preparation for the system to enter the protection mode; after that, the system executes arch/i386/kernel/head.S (for the compressed kernel, first execute arch/i386/boot/compressed/head.S); head. An assembly program setup_idt defined in S, which is responsible for creating a 256-item idt table (Interrupt Descriptor Table), which holds all the entry addresses of traps and interrupts; this includes the entry address of the system call master program system_call; Of course, in addition to this, head.S still has to do some other initialization work; The first kernel program that runs after system initialization, asmlinkage void __init start_kernel(void) is defined in /usr/src/linux/init/main.c by calling usr/src/linux/arch/i386/kernel/traps. A function in c __init trap_init(void) sets the entry address of each trap and interrupt service routine to the idt table, where the system call master program system_cal is one of the interrupt service routines; the void __init trap_init(void) function passes Call a macro set_system_gate(SYSCALL_VECTOR,&system_call); hang the entry of the system call master on interrupt 0x80; where SYSCALL_VECTOR is defined in /usr/src/linux/arch/i386/kernel/irq.h Constant 0x80; and system_call is the entry address of the interrupt master control program; the interrupt master program is defined in assembly language in /usr/src/linux/arch/i386/kernel/entry.S; 3. The interrupt master control program is mainly responsible Saves the state of the processor before executing the system call, checks whether the current call is legal, and causes the processor to jump to the corresponding system service routine stored in the sys_call_table table according to the system call vector. The recovery handler state is returned to the user program after returning from the system service routine; the system call vector is defined in /usr/src/linux/include/asm-386/unistd.h; the sys_call_table table is defined in /usr/src/In linux/arch/i386/kernel/entry.S; the user programming interface of the system call is also defined in /usr/src/linux/include/asm-386/unistd.h; 4. It can be seen that linux The system call is also like the int 21h interrupt service of the dos system. It takes the 0x80 interrupt as the total entry and then goes to the entry address of the various interrupt service routines stored in the sys_call_table table to form various interrupt services. Source code analysis shows that to add a system call, you must add an entry in the sys_call_table table, save the entry address of your system service routine, and then recompile the kernel. Of course, system service routines are essential. of. It can be seen that in this version of the Linux kernel source, the source files associated with the system call include the following: arch/i386/boot/bootsect.S arch/i386/Kernel/setup.S arch/i386/boot/compressed /head.S arch/i386/kernel/head.S init/main.c arch/i386/kernel/traps.c arch/i386/kernel/entry.S arch/i386/kernel/irq.h include/asm-386 /unistd.h Of course, this is just a few of the main files involved. In fact, adding system calls really wants to modify the file only include/asm-386/unistd.h and arch/i386/kernel/entry.S