Linux kernel device driver system call notes

/****************************
 * System call********************************/

(1) What is a system call?

The system call is the interface between the kernel and the application. If the application wants to access hardware devices and other operating system resources, it must do so through the system call.

In Linux, system calls are the only means for user space to access the kernel. Except for exceptions and interrupts, they are the only legal entry point to the kernel. The number of system calls is small, only about 300 on i386.

(2) Relationship between C library and system calls

Application programmers program through an application programming interface (API) in the C library rather than directly through system calls. The functions in the C library may not call system calls, or simply encapsulate a system call, or implement a function by calling multiple system calls.

Application --> C library --> kernel system call

From the programmer's point of view, system calls are irrelevant, they only need to deal with the API;

From the kernel's perspective, the kernel only deals with system calls. How library functions and applications use system calls is not the kernel's concern.

The Unix system call abstracts functions used to accomplish a specific purpose, and how to use these functions is the user's business, and the kernel does not care.

(3) System call functions implemented in the kernel

Example of using system calls in user space

#include <unistd.h>
getpid();

After being encapsulated by the glibc library, the function sys_getpid in kernel/timer.c in the kernel will eventually be called. See this function. All system call functions in the kernel begin with sys_.

• asmlinkage tells the compiler to use the local stack to pass parameters
• The FASTCALL macro tells the compiler to use registers to pass parameters.

(4) System call number

Because the system call must enter the kernel space from the user space, it cannot be completed through a simple function call, but must go through some special mechanisms supported by the processor (the so-called soft interrupt).

On x86, this special mechanism is the assembly instruction int $0x80, and on arm, it is the assembly instruction SWI.

This instruction is encapsulated into a function in the C library. When the program executes this instruction, the CPU will enter a special exception mode (or soft interrupt mode) and jump the program pointer to a specific location (such as 0x8 in the interrupt vector table for ARM).

Many system calls are implemented in the kernel. The addresses of these system calls are placed in a system call table in order. This table is an array called sys_call_table, with a total of NR_syscalls entries. Through this table, you can call all sys_ functions defined by the kernel

When calling the assembly instruction int $0x80 or SWI, a system call number must be passed at the same time. This system call number will be used as an index to select the corresponding system call from sys_call_table.

int80 saves the system call number in the eax register, while SWI integrates it directly into the instruction (like SWI 0x124).

(5) System call implementation mechanism

The function that handles system calls in the kernel is defined in system_call in arch/i386/kernel/entry.s, while the arm system is defined in vector_swi in arch/arm/kernel/entry-common.s. The system call table for the x86 system is defined in arch/i386/kernel/syscall_table.s (or directly in entry.s), while the arm system call table is defined in arch/arm/kernel/calls.s. The system call number is defined in include/asm/unistd.h

(6) What aspects should be paid attention to when implementing system calls

It is not difficult to add a system call to Linux, but how to design and implement a system call is the difficulty. Linux does not advocate the use of multi-purpose system calls (providing different functions based on different parameters).

System calls must carefully check the validity of incoming parameters, especially user-supplied pointers, and must ensure that:

• *The memory area pointed to by the pointer belongs to user space, and the process cannot trick the kernel into reading data in kernel space
• *The memory area pointed to by the pointer belongs to the address space of the process and cannot trick the kernel into reading data from other processes
• *A process cannot bypass memory access permissions.

When executing a system call, the kernel is in the process context and can sleep or be preempted, so the system call must be reentrant.

(7) An example of a system call (including kernel modification and user space program implementation)

Implement a system call sys_foo

a. Add system call number

Modify include/asm/unistd.h , add: #define __NR_foo 289 and modify: #define NR_syscalls 290

b. Add to the system call table

Modify arch/i386/kernel/entry.s or syscall_table.s and add:

.long sys_foo

c. System calls must be compiled into the core kernel image. The definition of the system call can be placed in the code that is most closely related to its function, such as kernel/sys.c, and add:

#include <asm/thread_info.h>
/* 
 * return the size of kernel stack
 */
asmlinkage long sys_foo(void)
{
 return THREAD_SIZE;
}

d. Calling in user space

Usually, system calls are supported by the C library, and glibc cannot support our own system calls. At this time, we need to use a set of macros provided by Linux itself to directly access the system calls.

man 2 syscall

Summarize

The above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. Thank you for your support of 123WORDPRESS.COM. If you want to learn more about this, please check out the following links