Linux System Call (1)

This is the first article in the Linux System Call series. It introduces the definition, basic principles, usage methods, and precautions of Linux system calls, this gives readers a general impression of Linux system calls.

What is system call?

A group of subprograms are set in the Linux kernel to implement various system functions, which are called system calls. You can use system invocation commands to call them in your own applications. From a certain perspective, system calls are very similar to common function calls. The difference is that system calls are provided by the core of the operating system and run in the core State. Common function calls are provided by function libraries or users and run in the user State. The two have similarities in usage, which will be mentioned below.

With Linux core, some C language function libraries are provided. These libraries pack and expand system calls because these library functions are closely related to system calls, these functions are also called system calls.

How many system calls are there in Linux?

This question is not so easy to answer, even if Linus torvaldz does not know it all at once.

In the 2.4.4 kernel, there are a total of 221 system calls in a narrow sense, you can go to the <kernel source directory>/include/asm-i386/unistd. h. You can also run the "Man 2 syscils" command to check their directories, many of the latest calls may not be included ). In a broad sense, system calls are implemented in the form of library functions. The number of these functions has never been counted. This is a thankless activity, and new kernels are constantly being launched, no one cares about the number of changes in each new kernel, at least not even the kernel modifier, because they have never published such a statement.

There is a sorted list together with this article, which cannot be very comprehensive, but common system calls are basically included. Only a few of them are commonly used, this topic will introduce them selectively.

Why use system call?

In fact, many c-language standard functions that we have become accustomed to. The implementation on the Linux platform relies on system calls. Therefore, if you want to have a deep understanding of the underlying principles of the system, understanding various system calls is a preliminary requirement. Furthermore, if you want to become a programming expert in Linux, which we often call hacker, one of the symbols of hacker can also have a thorough understanding of various system calls.

Even with the above reasons, you will find that in common programming, in many cases, system calling is a simple and effective way to implement your ideas, therefore, if possible, you should master some system calls as much as possible, which will bring unexpected help to your program design process.

How does a system call work?

Generally, a process cannot access the kernel. It cannot access the memory occupied by the kernel or call kernel functions. CPU Hardware determines this (that is why it is called "protection mode "). System calls are an exception to these rules. The principle is that the process first fills the register with appropriate values, and then calls a special command, which will jump to a location in a pre-defined kernel (of course, this location is readable but not writable by the user process ). In Intel CPU, this is implemented by the 0x80 interrupt. The hardware knows that once you jump to this position, you are not a user running in restricted mode, but the operating system kernel-so you can do whatever you want.

The kernel that a process can jump to is called sysem_call. This process checks the system call number, which tells the kernel process which service to request. Then, it looks at the system call table (sys_call_table) and finds the called kernel function entry address. Then, call the function and wait for some system checks to return to the process (or to other processes if the process time is exhausted ). If you want to read this code <Kernel source code directory>/kernel/entry. S, next line of entry (system_call.

How to Use System Call?

Let's look at an example:

# Include <Linux/unistd. h>/* define macro _ syscall1 */# include <time. h>/* define the type time_t */_ syscall1 (time_t, time, time_t *, tloc)/* macro, and then obtain the prototype of the time () function */main () {time_t the_time; the_time = Time (time_t *) 0);/* call time system call */printf ("the time is % LD/N", the_time );}

The system calls time to return the number of seconds that have elapsed since GMT, January 1, January 1, 1970.

This is the most standard form of system calling. The macro _ syscall1 () is expanded to obtain a function prototype. I will explain it in detail later. But in fact, if you change the program to the following, the program can run the same result.

# Include <time. h> main () {time_t the_time; the_time = Time (time_t *) 0);/* call time system call */printf ("the time is % LD/N ", the_time );}

This is because in time. H, the system call time has actually been implemented in the form of library functions, saving the call _ syscall1 macro for us to develop the function prototype.

Most system calls are implemented in various C language function libraries. Therefore, in general, we can call system calls just like calling common library functions, we have the opportunity to use the _ syscall * () macros.

_ Syscall?

Seven macros are defined in unistd. H, which are

_syscall0(type,name)_syscall1(type,name,type1,arg1)_syscall2(type,name,type1,arg1,type2,arg2)_syscall3(type,name,type1,arg1,type2,arg2,type3,arg3)_syscall4(type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4)_syscall5(type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4,type5,arg5)_syscall6(type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4,type5,arg5,type6,arg6)

They do not seem like macros, but they are actually

#define MAXSIZE 100

There is no difference in maxsize.

Their role is to form a prototype of the system call function for us to call in the program. We can easily find that the number behind _ syscall is as large as the number of typen and argn. In fact, the number following _ syscall indicates the number of parameters that form the function after expansion. Let's look at an instance, that is, the time system call we just used:

_syscall1(time_t,time,time_t *,tloc)

The expanded scenario is as follows:

time_t time(time_t * tloc){ long __res; __asm__ volatile("int $0x80" : "=a" (__res) : "0" (13),"b" ((long)(tloc))); do { if ((unsigned long)(__res) >= (unsigned long)(-125)) { errno = -(__res); __res = -1; } return (time_t) (__res); } while (0) ;}

We can see that _ syscall1 (time_t, time, time_t *, tloc) is expanded into a function named time. The original parameter time_t is the return type of the function, the original parameter time_t * And tloc constitute the parameters of the new function respectively. In fact, the prototype of the time function used in the program is it.

What is errno?

To prevent confusion with normal return values, the system does not directly return error codes, but puts the error codes in a global variable named errno. If a system call fails, you can read the errno value to confirm the problem.

The error messages represented by different errno values are defined in errno. H. You can also view them by running the "Man 3 errno" command.

It should be noted that the errno value is set only when a function error occurs. If the function does not have an error, the errno value is not defined and is not set to 0. In addition, it is best to store the value of errno into another variable before processing errno, because during error handling, the value of errno is changed even when a function like printf () fails.

Is the system call compatible?

Unfortunately, the answer is-not good. However, this does not mean that your program will crash after three days, because the system calls are provided by the Linux kernel, so they work very stably and do not have to worry about this point, in most cases, system calls are much more reliable and efficient than the code you write.

However, the compatibility of system calls between Linux kernel versions is not as good as imagined, which is determined by the nature of Linux itself. Linux is developed by a group of programming experts in their spare time. Most of them do not regard Linux as a serious commercial software (the current situation is somewhat different, with the growth of Linux commercial companies and Linux-based users, the brains of many people have changed .) The result is that if there is a conflict between the efficiency and compatibility of the new solution, they tend to discard compatibility and pursue efficiency. In this way, if they think that a system call is poorly implemented, they will not hesitate to make changes, and sometimes even get rid of interfaces. what's even more terrible is that they don't even say hello to their modifications, the modification prompt cannot be found in any document. In this way, whenever the new kernel is launched, it is very likely that some system calls will be quietly updated, and user-compiled applications will also go wrong.

Speaking of this, do you feel that your future is dark? Well, don't be too nervous. As we mentioned earlier, as more and more people regard Linux as their own rice bowl, incompatibility is becoming increasingly rare. Linux Kernel Versions later than Version 2.2 are already very stable. However, it is still necessary to test the compatibility of your applications after each new kernel is released to prevent unexpected occurrence.

How can I learn how to use a Linux system?

You can use the "Man 2 system call name" command to view the introduction of each system call, but this requires you to have a good basic English, secondly, you have to have some skills in programming and system programming. man pages won't involve too many application details, because it is just a manual rather than a tutorial. If what man pages provides cannot satisfy you very much, come with me. This column will show you the Infinite Charm of programming for Linux system calls.

There are two small requirements for readers:

1) Readers must have certain C programming experience;

2) Readers must have certain experience in Linux. If you can fully understand what this article says from the beginning to here, you will be qualified. Pack your bags and prepare for departure!