Linux kernel service routines and system call interface

1. Generating System Call Routines with Macros High-level language applications generally do not have direct access to kernel functions. However, there are always some advanced users who need to access kernel functions. If you let users write assembly language programs to achieve kernel trapping, it is obviously inappropriate because it is neither safe nor conforms to the original intention of setting up the operating system. Users provide a friendly program to set up a juice platform. Since the system call routines used to encapsulate kernel service routines have a fixed framework, in order to simplify the packaging of kernel service routines, Linux defines six macros from _sysca110~_sysca115 that advanced users can use. Wrap the required kernel service routines as system call routines. The number after the names of the above six macros indicates the number of parameters (except the system call number) that can be used by the encapsulated kernel service routine. When the above macros encapsulate the kernel service routines, Linux specifies that the number of parameters passed to the macro should be twice the number of parameters required by the kernel service routine plus 2, ie 2(n+1), where ″ Is the number of parameters called by the system. In other words. For each parameter of the kernel service routine, two parameters must be used in the macro: a name to indicate the parameter, and a type to indicate the parameter. Two parameters are also appended, which are used to express the name and type of the return value of the system call. For example, when you use a macro to encapsulate the kernel service routine write(), you should call the macro syscall3 in the following format: _syscall3(int, write, int, fd, cONst char*, buf, unsingnde int, count) where: int And wrlte are the type and name of the return value; int and fd are the type and name of the parameter fd; const char* and buf are the type and name of the parameter buf; unsigned lnt and count are the type and name of the parameter count. 2. System Call Interface In general, as a well-established operating system, it is not going to let the user application directly use the name similar. The svsxyz() form of the system uses routines to call kernel service routines. Therefore, it is usually necessary to provide a common interface with the normal function in the high-level language above the system call routine, so that the user feels as convenient as using the ordinary function when using the system service through this interface.