[Linux] System call understanding (1)

This article is the first of a series of Linux system invocation columns, and the definition, rationale, usage, and considerations for Linux system calls is probably introduced to make a general impression on Linux system calls.

What is a system call?

The Linux kernel sets up a set of subroutines that are used to implement various system functions, called system calls. Users can invoke them in their own applications through system invoke commands. From a certain point of view, a system call is very similar to a normal function call. The difference is only that the system call is provided by the operating system core, and the normal function call is provided by the function library or the user itself, running in the user state. There are similarities in the way they are used, as will be mentioned below.

Along with the Linux core, there are a number of C-language libraries that have packaged and extended system calls, because these library functions are very closely related to system calls, so it is customary to refer to these functions as system calls.

How many system calls does the Linux party have?

This question is not very good to answer, even if let Linus Torvaldz oneself also not to be able to speak clearly in a sudden.

In the 2.4.4 kernel, there are 221 system calls in the narrow sense, you can find their original in the < kernel source directory >/include/asm-i386/unistd.h, you can also command "Man 2 Syscalls" Look at their directories (the version of man pages is generally older, and many of the latest calls are not included). Generalized system calls, that is, in the form of library functions, those who have never counted, this is a thankless job, the new kernel is constantly launched, each new kernel changes in the number of functions no one cares, at least even the kernel of the modifier himself does not care, Because they have never published a declaration of this kind.

With this article there is a sorted list, it can not be very comprehensive, but the common system calls are already included, there are only a few of the parts you usually use, this column will be selected to introduce them.

Why use a system call?

In fact, many of the C language standard functions that we have become accustomed to, the implementation of Linux platform is done by the system call, so if you want to understand the underlying principles of the system, mastering the various system calls is a preliminary requirement. Further, if you want to become a Linux programming master, which is what we often say hacker, one of its flags is also able to have a thorough understanding of various system calls.

Even if you remove the above reasons, in the usual programming you will also find that in many cases, the system call is to implement your ideas in a concise and effective way, so it is possible to learn as much as possible to master some system calls, which will bring unexpected help to your program design process.

How does a system call work?

In general, a process cannot access the kernel. It cannot access the kernel's occupied memory space, nor can it call kernel functions. The CPU hardware determines these (which is why it is referred to as "protected mode"). System calls are an exception to these rules. The principle is that the process populates the register with the appropriate values and then invokes a special instruction that jumps to a location in a pre-defined kernel (which, of course, is readable but not writable by the user process). In the Intel CPU, this is implemented by the interrupt 0x80. The hardware knows that once you jump to this location, you are not the user running in restricted mode, but as the kernel of the operating system-so you can do whatever you like.

The kernel location that the process can jump to is called Sysem_call. This procedure checks the system call number, which tells the kernel process which service to request. It then looks at the system call table (Sys_call_table) to find the calling kernel function entry address. Next, just call the function, wait for the return, do some system check, and finally return to the process (or to other processes if the process runs out of time). If you want to read this code, it's in the < kernel source directory >/kernel/entry. The next line of S,entry (System_call).

How do I use system calls?

Let's look at an example:

#include <linux/unistd.h>/* Define macros _syscall1*/#include <time.h>     /* Define type TIME_T*/_SYSCALL1 (Time_t,time, time_t *,tloc)/    * macro, expand to get the time () function prototype */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 call time returns the number of seconds from January 1, 1970 0:00 GMT. This is the most standard form of system invocation, Macro _SYSCALL1 () expands to get a function prototype, which I'll explain in more detail later. But in fact, if the program is changed to the following, the program can also 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 the time.h actually already implemented in the form of the library function the time this system call, for us to eliminate the call _SYSCALL1 macro expansion to get the function prototype this step.

Most system calls are implemented in a variety of C-language function libraries, so in general we can call the system calls like normal library functions, only in very rare cases, we have the opportunity to use _syscall* ().

What is _syscall* ()?

7 macros are defined in Unistd.h, respectively

_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 don't look much like macros, but their substance and
#define MAXSIZE 100
There is no difference in the maxsize.

Their role is to form a corresponding system call function prototype for us to invoke in the program. It is easy to find the law, _syscall the number of the back is as many as the typen,argn. In fact, the numbers following the _syscall indicate the number of arguments that are formed after the expansion, so let's look at an instance of the time system call that we just used:

_SYSCALL1 (time_t,time,time_t *,tloc)

　　

This is the case when the expansion occurs:

time_t Time   (time_t *   tloc) {    long __res;    __asm__ volatile ("int $0x80": "=a" (__res): "0" (+), "B" ((long) (Tloc)));    Do {        if (unsigned long) (__res) >= (unsigned long) ( -125)) {            errno =-(__res);            __res  =-1;        }        Return (time_t) (__res);    } while (0);}

　　

As can be seen, _syscall1 (time_t,time,time_t *,tloc) expands into a function named time, the original parameter time_t is the return type of the function, the original parameters time_t * and Tloc constitute the parameters of the new function respectively. In fact, it is the prototype of the time function used in the program.

What is errno?

To prevent confusion with normal return values, the system call does not return the error code directly, but instead put the error into a global variable named errno. If a system call fails, you can read out the value of errno to determine where the problem lies.

errno the error messages represented by different values are defined in errno.h, you can also view them by command "Man 3 errno".

It is important to note that the value of errno is only set when the function has an error, and if the function does not have an error, the value of errno is undefined and will not be reset to 0. In addition, it is best to put its value in another variable before processing errno, because in error handling, even functions like printf () will change the value of errno when an error occurs.

is System call compatibility good?

Unfortunately, the answer is--not good. But this does not mean that your program will Zooey cause the system to crash, because the system calls are provided by the Linux kernel, so they work very stably, there is no doubt about this point, in the vast majority of cases, the system call is more reliable and efficient than the code you write yourself.

However, the compatibility of system calls between kernel versions of Linux is not as good as imagined, which is determined by the nature of Linux itself. Linux is a group of programmers using their spare time to develop, most of them do not regard Linux as a serious business software, (the situation is somewhat different now, with the growth of Linux business companies and Linux-based people, many people's brains have changed. As a result, if the new scheme is inconsistent in efficiency and compatibility, they tend to abandon compatibility and pursue efficiency, so that if they think a system call implementation is worse, they will not hesitate to make changes, and sometimes even the interface has been changed, and, more frightening, many times, They didn't even say hello to their changes, and they couldn't find any hints about the changes in any of the documents. This way, whenever the new kernel is launched, it is likely that some system calls will be silently updated, and the user-compiled application will follow the error.

Speaking of which, do you feel the future is dim? Oh, don't be too nervous, as mentioned earlier, as more and more people regard Linux as their own rice bowls, incompatible with the situation is increasingly rare. The Linux kernel has been very stable since the 2.2 release, but you still need to test your application for compatibility after each new kernel is launched to prevent accidental occurrences.

How do I learn to use Linux system calls?

You can use the "Man 2 system call name" command to see the introduction of each system call, but this first requires you to have a good English foundation, followed by a certain program design and system programming skills, man pages will not involve too much application details, because it is a manual rather than tutorial. If man pages doesn't make you feel very satisfied, come with me, this column will show you the power of Linux system invoke programming.

Although this column is not a very advanced technical article, but also to the reader has two small requirements: 1 readers must have a certain degree of C programming experience, this column will not be overly entangled in the language details; 2) readers must have some experience with Linux, and this column does not intend to make a fuss about Linux applications. To give a small test, if you can fully understand the article from the beginning to here, you are qualified. Pack your bags and get ready to go!

Attached: "Linux system call list"

Resources

• Linux Mans pages
• The Linux Programmer ' s guider, Sven Goldt & Sven van der Meer & Scott Burkett & Matt welsh,1995
• Computer operation system, soup son Ying Zhe feng screen Tang Xiaodan, Xidian University Press, 2000
• IBM system call to learn from me

[Linux] System call understanding (1)