20135201 Li Chenxi "Three layers of skin" in the fifth week of "Linux kernel Analysis" (bottom)

Li Chenxi Original works reproduced please specify the source "Linux kernel analysis"

MOOC Course http://mooc.study.163.com/course/USTC-100002900

I. Adding time and TIME-ASM commands to Menusos 1. Procedure

into the lab building.

1. First, force the deletion of the current menu

2. Clone a new menu

3. After entering the menu, enter make Rootfs to automatically compile

4. By entering help, you can see that the system supports more commands:
   • Help
   • Version
   • Quit
   • Time
   • Time-asm
5. So how is time and time-asm implemented?
   • After entering test.c, look at the main function. There are only two statements associated with it:
   • Menuconfig ("Time", "Show system Time", time);
   • Menuconfig ("Time-asm", "Show system Time", Time (ASM));

6. To add the time and Time_asm commands to Menuos:

• Update the menu code to the latest version
• TEST.c in main function, add Menuconfig ()
• Add the corresponding time function and Timeasm function
• Make Rootfs

Two. Call the kernel function sys_time1 using the GDB tracking System. Procedure

1. Enter kernel, freeze boot

   qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img -s -S

2. Start gdb)
3. Load Debug version kernel and connect to target address )
4. Time is executed in menuos after the system call to sys time for the time function is set to a breakpoint. The discovery system stops at Systime. Continue to press N to step into the schedule function.
5. Sys_time returned and entered assembly code processing, GDB could not continue tracking
6. If you set a breakpoint at SYS call(entry32.S) and then enter C, you will find that it is not stopped at Sys_call (because this is a system calling function instead of a normal function)

The code is as follows:

Qemu-kernel Linux-3.18. 6/arch/x86/boot/bzimage-initrd rootfs.img-s-S

GDB (gdb) file Linux-3.18. 6/vmlinux//Load symbol table

(GDB) Target remote:1234 //connection

B sys_time: Set breakpoints at the point where the system calls time

C: Continue execution, stop at breakpoint

N/S: Single-step operation, s enter function, n does not enter

Understand the main code between System_call to Iret

A process call may occur before the system call returns, and the process context switch occurs.

从系统调用入口开始：ENTRY(system_call)SAVE_ALL //保存现场system_call：    call *system_call_table(,%eax,4) //调用了系统调用处理函数，有系统调用号eax中，是实际的系统调用处理程序。当前任务syscall_exit_work里面有work_pending里面有work_notifysig //处理pending信号，不用管重要的是work_resched:call schedule //决定了进程调度的代码，调用完会跳转到restore_allrestore_all //恢复现场INTERRUPT_RETURN //irp_return宏，中断处理过程在这结束

Third, the system calls in the kernel code processing process 1.int 0x80 instruction and system call is linked by an interrupt vector, while the API and the corresponding SYSA [function] is a 2 that is linked by a system call number. Initialization of the system invocation mechanism

1. The trapgate function involves the interrupt vectors of the system calls andthe assembly code entry of the systems call; once the int 0x80,cpu is executed, jump directly to System_call

3. Simplified, easy-to-understand System_call pseudo-code

• The next instruction in int 0x80 starts at entry (System_call) from here
• Process scheduling may occur before system calls return (call schedule)
• Current process may have signal to be processed (WORK_NOTIFYSIG)
• Interrupt context switching and process context switching occur in process scheduling, which is a coherent process
• The kernel can be abstracted into a collection of different interrupt processing processes

4. Simply browse the main code between System_call and Iret

1. Save_all: Save Site
2. Syscall_call: Called the system call handler function
3. Restore all: Recovering the scene (because the system calls the handler function is also a special "interrupt")
4. Syscallexitwork: as described in 3.
5. INTERRUPT RETURN: That is iret, the system calls to this end

Summarize and clarify your understanding of the "system call processing Process".

System calls are a special kind of interrupt. It is writing a function, it needs to use the code in the kernel, but this part of the code I have no way to access directly, so I call through the system, it says it helps me to let the kernel execute the code I want to execute, the final results tell me. At this point, I as a user is nothing to know, waiting for the system call to tell me the result. System calls, it first through the SYS_ call this function and the core communication, said I want to use your sys_ xxx function, please tell me the results of this function execution. The kernel will soon go to its own interior, perform sys_ xxx function, after the execution, the kernel tells the system call, the function of the result of execution. Finally, the system calls the result to the user through the iret instruction. In this way, the user is perfect after the request system calls the help, easy to solve the problem.

20135201 Li Chenxi "Three layers of skin" in the fifth week of "Linux kernel Analysis" (bottom)