Introduction to Linux kernel Interpretation

Linux Kernel introduction-general Linux technology-Linux programming and kernel information. For more information, see the following section. Many Linux enthusiasts are very interested in the kernel but cannot start with it. This article aims to introduce a method to get started with interpreting the Linux kernel source code, rather than explaining the complicated Linux kernel mechanism.
1. file organization of the core source program
(1) Linux core source code is usually installed in/usr/src/Linux, and it has a very simple numbering Convention: Any even number of core (intermediate number) such: 2.0.30 is the core of a stable release, and any odd-number core such as 2.1.42 is the core of development.
This article is based on the stable 2.2.5 source code. The second part of the implementation platform is Redhat Linux 6.0.
(2) The core source program files are organized in a tree structure. At the top of the source program tree, you will see the following directories:
Arch: the arch sub-directory contains all the core Code related to the architecture. Each of its subdirectories represents a supported architecture. For example, i386 is a subdirectory about Intel cpu and its compatible architecture. Generally, PCs are based on this directory;
Include: The include sub-Directory includes most of the header files required for compiling the core. Platform-independent header files are in the include/linux subdirectory, Intel CPU-related header files are in the include/asm-i386 subdirectory, And the include/scsi directory is the header file directory of the SCSI device;
Init: This directory contains the core initialization code (Note: it is not the System Boot Code) and contains two files main. c and Version. c. This is a very good starting point for studying how the core works;
Mm: This Directory includes all memory management code independent of the CPU architecture, such as page-based storage management memory allocation and release, the Memory Management Code related to the architecture is located at arch/*/mm/, for example, 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. Similarly, the Code related to the architecture is in arch/*/kernel;
Drivers: Place all the device Drivers in the system. Each driver occupies a sub-directory, for example, a block Device Driver Under/block, such as ide. c ). If you want to check how all devices that may contain a file system are initialized, you can check the device_setup () function in drivers/block/genhd. c. It not only initializes the hard disk, but also the network, because the network is required when installing the nfs file system.
Other directories such as Lib: the library code with the core; Net: The Code related to the core and the network; Ipc: the code that contains the communication between the core processes; Fs: all File System Code and various types of file operation code. Each subdirectory of the Code supports a file system, such as fat, ext2, and Scripts. This directory contains the script files used to configure the core.
Generally, there is. the depend file and a Makefile file are both auxiliary files used during compilation. reading these two files carefully is helpful for figuring out the relationship and dependency between each file, in addition, there are Readme files in some directories, which are descriptions of the files in this directory, which is also conducive to our understanding of the kernel source code.
2. interpreting practice: Add a system call for your Kernel
Although the Linux kernel source code is organized reasonably and scientifically in a tree structure, all files associated with functions are placed under the same subdirectory, which makes the program more readable. However, the Linux kernel source code is too large and complex. Even if a reasonable file organization method is adopted, there are still many associations between files under different directories, part of the code at the analysis core usually needs to view several other related files, and these files may not be in the same subdirectory.
The following is a specific Kernel Analysis instance. We hope that you can use this instance to understand the Linux kernel organization. You can also learn some kernel analysis methods.
The following is an analysis instance:
(1) operating platform
Hardware: CPU Intel Pentium II;
Software: Redhat Linux 6.0, kernel version 2.2.5
(2) kernel source code analysis
① System boot and initialization: There are several boot methods for Linux systems, including Lilo, Loadin, and Linux Bootstrap (bootsect-loader ), the source program corresponding to the latter is arch/i386/boot/bootsect. s, which is an assembly program of the actual mode, is not analyzed here. Regardless of the boot mode, you must jump to arch/i386/Kernel/setup. S. Setup. S is mainly used for initialization in real mode to prepare the system for entering the protection mode. After that, the system executes arch/i386/kernel/head. S (perform arch/i386/boot/compressed/head for the compressed kernel. s); head. setup_idt, an assembly program defined in S, is responsible for creating an idt Table (Interrupt Descriptor Table) with 256 items. This Table stores all the inactive and inactive endpoints, this includes the entry address of system_call. Of course, in addition, head. S has to do some initialization work.
② The first kernel program asmlinkage void _ init start_kernel (void) that runs after system initialization is defined in/usr/src/linux/init/main. in c, it calls usr/src/linux/arch/i386/kernel/traps. in c, the void _ init trap_init (void) function sets the entry addresses of each self-trapped and interrupted service program to the idt table. The system calls the general control program system_cal, which is one of the interrupt service programs; the void _ init trap_init (void) function calls a macro set_system_gate (SYSCALL_VECTOR, & system_call) to hook the entry of the System Call Control Program to the interrupt 0x80.
SYSCALL_VECTR is defined in/usr/src/linux/arch/i386/kernel/irq. A constant of 0x80 in h, and system_call is the entry address for interrupting the Master Control Program, the interrupt control program is defined in/usr/src/linux/arch/i386/kernel/entry. s.
③ The interrupt general control program is mainly responsible for saving the status before the processor executes the system call, checking whether the current call is legal, and according to the system call vector, redirect the processor to the entry of the corresponding system service routine saved in the sys_call_table table, restore the processor status and return it to the user program.
The system call vector is defined in/usr/src/linux/include/asm-386/unistd. in h, the sys_call_table table is defined in/usr/src/linux/arch/i386/kernel/entry. s, and at the same time in/usr/src/linux/include/asm-386/unistd. h also defines the User Programming Interface called by the system.
④ It can be seen that the Linux system calls are also like the int 21h interrupt service of the DOS system. A large number of 0x80 interruptions are used as the total entry point, and then transferred to the entry address of various interrupt service routines stored in the sys_call_table table, different types of interrupt services are provided.
The source code analysis shows that to add a system call, you must add an item to the sys_call_table table, save the entry address of your system service routine, and re-compile the kernel. Of course, system service routines are essential.
We can see that in the Linux kernel source program <2.2.5> of this version, the source program files related to system calls include the following:
* Arch/i386/boot/bootsect. S
* Rch/i386/Kernel/setup. S
* Rch/i386/boot/compressed/head. S
* Rch/i386/kernel/head. S
* Nit/main. c
* Rch/i386/kernel/traps. c
* Rch/i386/kernel/entry. S
* Rch/i386/kernel/irq. h
* Nclude/asm-386/unistd. h
Of course, this is only a few of the main files involved. In fact, the added system calls really need to modify the file only include/asm-386/unistd. h and arch/i386/kernel/entry. S.
(3) source code modification
① The System Service Routine added to kernel/sys. c is as follows:
Asmlinkage int sys_addtotal (int numdata)
{Int I = 0, enddata = 0;
While (I <= numdata)
Enddata + = I ++;
Return enddata ;}
This function has an int-type entry parameter numdata and returns the accumulated value from 0 to numdata. However, you can also place the system service routine in a custom file or other file, only necessary instructions should be made in the corresponding file.
② Add the entry address of smlinkage int sys_addtotal (int) to the sys_call_table table.
The last few lines of source code in arch/i386/kernel/entry. S are changed:
. Long SYMBOL_NAME (sys_sendfile)
. Long SYMBOL_NAME (sys_ni_syscall)/* streams1 */
. Long SYMBOL_NAME (sys_ni_syscall)/* streams2 */
. Long SYMBOL_NAME (sys_vfork)/* 190 */
. Rept NR_syscalls-190
. Long SYMBOL_NAME (sys_ni_syscall)
. Endr
After modification:
. Long SYMBOL_NAME (sys_sendfile)
. Long SYMBOL_NAME (sys_ni_syscall)/* streams1 */
. Long SYMBOL_NAME (sys_ni_syscall)/* streams2 */
. Long SYMBOL_NAME (sys_vfork)/* 190 */
/* Add by I */
. Long SYMBOL_NAME (sys_addtotal)
. Rept NR_syscalls-191
. Long SYMBOL_NAME (sys_ni_syscall)
. Endr
③ Make necessary declarations in include/asm-386/unistd. h for user and other system processes to query or call the vector corresponding to the added sys_call_table table item.
The added part of the/usr/src/linux/include/asm-386/unistd. h file is as follows:
# Define _ NR_sendfile 187
# Define _ NR_getpmsg 188
# Define _ NR_putpmsg 189
# Define _ NR_vfork 190
/* Add by I */
# Define _ NR_addtotal 191
④ Test. c is as follows:
# Include
# Include
_ Syscall1 (int, addtotal, int, num)
Main ()
{Int I, j;
Do
Printf (\ "Please input a numbern \");
While (scanf (\ "% d \", & I) = EOF );
If (j = addtotal (I) =-1)
Printf (\ "Error occurred in syscall-addtotal (), n \");
Printf (\ "Total from 0 to % d is % d n \", I, j );}
Compile the new kernel after modification and guide it as a new operating system. After running several programs, you can see that everything is normal; compile the test program in the new system (Note: because the original kernel does not provide this system call, only in the new kernel after compilation, this test program may be compiled and passed). The running conditions are as follows:
$ Gcc. test. c
$./Test
Please input a number
36
Total from 0 to 36 is 666
After the modification is successful, further analysis of the source code shows that in the kernel of this version, from/usr/src/linux/arch/i386/kernel/entry. the settings of sys_call_table in the S file show that the service routines called by several systems are defined in/usr/src/linux/kernel/sys. the same function in c:
Asmlinkage int sys_ni_syscall (void)
{Return-ENOSYS ;}
For example, this is true for items 188th and 189th:
. Long SYMBOL_NAME (sys_sendfile)
. Long SYMBOL_NAME (sys_ni_syscall)/* streams1 */
. Long SYMBOL_NAME (sys_ni_syscall)/* streams2 */
. Long SYMBOL_NAME (sys_vfork)/* 190 */
The two items are declared in the file/usr/src/linux/include/asm-386/unistd. h as follows:
# Define _ NR_sendfile 187
# Define _ NR_getpmsg 188/* some people actually want streams */
# Define _ NR_putpmsg 189/* some people actually want streams */
# Define _ NR_vfork 190
It can be seen that in the kernel source code of this version, the asmlinkage int sys_ni_syscall (void) function does not perform any operation, so several system calls, including getpmsg and putpmsg, do not perform any operation, that is, the air conditioners to be expanded are used, but they still occupy the sys_call_table table items. It is estimated that they are arranged by the designers to facilitate the expansion of system calls, therefore, you only need to add the corresponding service routines (for example, add the service routines getmsg or putpmsg) to increase system calls.
3. Conclusion
To fully interpret the huge and complex Linux kernel, an article is far from clear, and the Code related to system calling is only a tiny part of the kernel. What is important is the method, therefore, the above analysis only plays a guiding role, and the real analysis remains to be done by the readers.