System Calls in Unix and Windows

The interface between a process and an operating system is provided by system calls. In general, system calls are available as assembly language instructions. They are also included in the manuals used by the assembly level programmers.

Unix System Calls

System calls in Unix are used for file system control, process control, interprocess communication etc. Access to the Unix kernel is only available through these system calls. Generally, system calls are similar to function calls, the only difference is that they remove the control from the user process.

There are around 80 system calls in the Unix interface currently. Details about some of the important ones are given as follows —

System Call	Description
access()	This checks if a calling process has access to the required file
chdir()	The chdir command changes the current directory of the system
chmod()	The mode of a file can be changed using this command
chown()	This changes the ownership of a particular file
kill()	This system call sends kill signal to one or more processes
link()	A new file name is linked to an existing file using link system call.
open()	This opens a file for the reading or writing process
pause()	The pause call suspends a file until a particular signal occurs.
stime()	This system call sets the correct time.
times()	Gets the parent and child process times
alarm()	The alarm system call sets the alarm clock of a process
fork()	A new process is created using this command
chroot()	This changes the root directory of a file.
exit()	The exit system call is used to exit a process.

Windows System Calls

System calls in Windows are used for file system control, process control, interprocess communication, main memory management, I/O device handling, security etc. The programs interact with the Windows operating system using the system calls. Since system calls are the only way to access the kernel, all the programs requiring resources must use system calls.

Details about some of the important system calls in Windows are given as follows —

System calls in linux and windows

Copyright (C) 1999-2000 by Konstantin Boldyshev

This list is NOT READY and is under heavy construction, a lot of entries are missing, and some may be incorrect. This is more a template than a real document. Meanwhile, I suggest you to examine this list by H-Peter Recktenwald.

Table of Contents (template)

1. Introduction

2. System call in depth

2.1 What is system call?
2.2 View from the Kernel side
2.3 View from the userland
2.4 Using system calls

3. Linux/i386 system calls

4. References

1. Introduction

First of all note that these are not libc «system calls», but real system calls provided by Linux Kernel.

List is intended to cover Linux 2.4 / 2.2 / 2.0.

2. System call in depth

3. Linux/i386 system calls

All system calls introduced/removed in specific Linux version are marked with (VER+/-) label (f.e. 2.2+ means that this call was introduced in Linux 2.2, and is missing in Linux 2.0). Square brackets hold real kernel name of system call from arch/i386/kernel/entry.S (as appeared in Syntax), if it differs from «official» in include/asm-i386/unistd.h.

Complete list of system calls with description

0. sys_setup

Syntax: int sys_setup(void)

Action: return -ENOSYS on Linux 2.2

Details: old sys_setup call

1. sys_exit

Syntax: int sys_exit(int status)

Action: terminate the current process

Details: status is return code

2. sys_fork

Syntax: int sys_fork()

Action: create a child process

3. sys_read

Syntax: ssize_t sys_read(unsigned int fd, char * buf, size_t count)

Action: read from a file descriptor

4. sys_write

Syntax: ssize_t sys_write(unsigned int fd, const char * buf, size_t count)

Action: write to a file descriptor

5. sys_open

Syntax: int sys_open(const char * filename, int flags, int mode)

Action: open and possibly create a file or device

6. sys_close

Syntax: sys_close(unsigned int fd)

Action: close a file descriptor

7. sys_waitpid

Syntax: int sys_waitpid(pid_t pid,unsigned int * stat_addr, int options)

Action: wait for process termination

8. sys_creat

Syntax: int sys_creat(const char * pathname, int mode)

Action: create a file or device

9. sys_link

Syntax: int sys_link(const char * oldname, const char * newname)

Action: make a new name for a file

10. sys_unlink

Syntax: int sys_unlink(const char * pathname)

Action: delete a name and possibly the file it refers to

11. sys_execve

Syntax: int sys_execve(struct pt_regs regs)

Action: execute program

12. sys_chdir

Syntax: int sys_chdir(const char * filename)

Action: change working directory

13. sys_time

Syntax: int sys_time(int * tloc)

Action: get time in seconds

14. sys_mknod

Syntax: int sys_mknod(const char * filename, int mode, dev_t dev)

Action: create a directory or special or ordinary file

15. sys_chmod

Syntax: int sys_chmod(const char * filename, mode_t mode)

Action: change permissions of a file

16. sys_lchown

Syntax: int sys_lchown(const char * filename, uid_t user, gid_t group)

Action: change ownership of a file

17. sys_break

Syntax: int sys_break()

Action: return -ENOSYS

Details: call exists only for compatibility

18. sys_oldstat

Syntax: int sys_stat(char * filename, struct __old_kernel_stat * statbuf)

19. sys_lseek

Syntax: off_t sys_lseek(unsigned int fd, off_t offset, unsigned int origin)

Action: reposition read/write file offset

20. sys_getpid

Syntax: int sys_getpid(void)

Action: get process identification

21. sys_mount

Syntax: int sys_mount(char * dev_name, char * dir_name, char * type, unsigned long new_flags, void * data)

Action: mount filesystems

22. sys_umount

Syntax: int sys_oldumount(char * name)

Action: unmount filesystem

23. sys_setuid

Syntax: int sys_setuid(uid_t uid)

Action: set user identity

24. sys_getuid

Syntax: int sys_getuid(void)

Action: get user identity

25. sys_stime

Syntax: int sys_stime(int * tptr)

Action: set time

26. sys_ptrace

Syntax: int sys_ptrace(long request, long pid, long addr, long data)

Action: process trace

27. sys_alarm

Syntax: unsigned int sys_alarm(unsigned int seconds)

Action: set an alarm clock for delivery of a signal

28. sys_oldfstat

Syntax: int sys_fstat(unsigned int fd, struct __old_kernel_stat * statbuf)

29. sys_pause

Syntax: int sys_pause(void)

Action: wait for signal

30. sys_utime

Syntax: int sys_utime(char * filename, struct utimbuf * times)

Action: change access and/or modification times of an inode

How can I make Linux system calls from a C/C++ application, without using assembly, and in a cpu-independent manner? [closed]

Want to improve this question? Update the question so it’s on-topic for Stack Overflow.

Closed 2 years ago .

I am looking to write a program that will need to do low level work with processes (ie. using the fork system call, among others). This program is to be written in C++ and is to run only on Linux. Ideally, it will be portable across CPU architectures (ie. x86, x86_64, and arm) with nothing more than a recompile, but I only really need x86_64 support.

As each Linux system call takes a number of arguments and returns a number of arguments in cpu registers (often only 1 return value), then a C function wrapper for each system call is likely easy to make. Also, because, AFAIK, system calls, being implemented in the kernel, have identical arguments and return values, if different assembly-level implementations, the same C interface can be exposed.

Does such a thing exist? If so, how can I access it?

Where is its documentation (list of available functions, their arguments with an explanation, and an explanation of exactly what the function does)?

2 Answers 2

libc already includes the wrapper functions you’re looking for. The prototypes for many of them are in #include , as specified by POSIX.

C is the language of low-level systems program on Unix (and Linux), so this has been a thing since Unix existed. (Providing wrapper functions in libc is easier than teaching compilers the difference between function call and system calls, and allows for setting errno on errors. It also allows for tricks like LD_PRELOAD to intercept system calls in user-space.)

The man pages for system calls are in section 2, vs. section 3 for library functions (which might or might not use system calls as part of their implementation: math.h cos(3) , ISO C stdio printf(3) and fwrite(3) , vs. POSIX write(2) ).

execve(2) is the system call.

See execl(3) and friends are also part of libc, and eventually call execve(2) . They are convenience wrappers on top of it for constructing the argv array, doing $PATH lookup, and passing along the current process’s environment. Thus they’re classed as functions, not system calls.

See syscalls(2) for an overview, and complete list of system Linux calls with links to their man-page wrappers. (I’ve linked the Linux man pages, but there are also POSIX man pages for all of the standard system calls.)

In the unlikely case that you’re not linking libc, you can use macros like MUSL’s syscall2 / syscall3 / etc. macros (the number is the arg count) to inline the right asm on whatever platform. You use __NR_write from asm/unistd.h to get system call numbers.

But note that the raw Linux system calls might have small differences from the interface provided by the libc wrappers. For example, they won’t check for pthreads cancellation points, and brk / sbrk requires bookkeeping in user-space by libc.

See SYSCALL_INLINE in Android for a portable raw sys_write() inline wrapper using MUSL macros.

But if you are using libc like a normal person for functions like malloc and printf , you should just use its system call wrapper functions.

The syscalls(2) man page lists every system call available on Linux (and gives a link to the documentation of each of them). Most of them have their C wrapper in libc (for example, write(2), fork(2) etc etc. ). A typical system call wrapper manages the calling conventions (see x86 ABI specifications here) and sets errno(3) on failure. ALP is a good but old introduction to Linux system programming, but you might find something newer (and ALP don’t mention recent system calls like signalfd(2) because when ALP was written, these system calls did not exist).

Most C standard library implementations (e.g. your libc.so ) on Linux provide the POSIX interface to system calls. And they usually are free software (e.g. GNU glibc or musl-libc and others). So if you care about gory implementation details (you usually shouldn’t), study (or improve) their source code.

Very few system calls are not interfaced by the libc, because they are unusual and don’t make much sense in C code. For example, sigreturn(2), socketcall(2), gettid(2) (or renameat2(2); you’ll use renameat instead). If you really need to use these directly (which is improbable and likely to be a design bug in your program) you need to code some assembler code (specific to your system and instruction set architecture) or perhaps use syscall(2).

Some system calls evolved with time or appeared in later kernels but did not exit ten years ago. The system call numbers (as understood by the kernel) might be listed in some asm/unistd_64.h file (which you probably don’t want to include, prefer sys/syscalls.h instead). For example, the preadv(2) syscall is redirected to either __NR_preadv or __NR_preadv2 but your libc should be clever enough to do the best it can.

Some new system calls did not exist in old kernels. A recent libc might in that case «emulate» them otherwise. But you should trust your libc implementation (and your kernel) most of the time. In practice, libc.so is the cornerstone of your Linux system and distribution (and you’ll better use it as shared library and avoid statically linking it because of nsswitch.conf(5)). If you need to understand in details how shared libraries work, read Drepper’s How to Write Shared Libraries. If you want some gory details about the system call mechanism in userland, see perhaps Assembler HowTo.

In almost all cases, you write somehow portable C code and use only the functions documented in syscalls(2) (as having a C wrapper) and intro(2).

In practice your shell-like program would use fork(2), execve(2), waitpid(2) etc. All these are specified by POSIX and available (and wrapped) in libc . You could study the source code of some free software shell for inspiration.