syscalls(2)

okay so bestie, you've stumbled into syscalls(2) from the System Calls Manual and honestly? this is the blueprint. the origin story. the one that explains why literally every other syscall manpage exists. ๐Ÿฆ‹


๐Ÿ’– NAME ๐Ÿ’–

syscalls โ€” Linux system calls

that's it. that's the name. short, sweet, iconic. ๐Ÿ’…

โœจ SYNOPSIS โœจ

Linux system calls.

likeโ€ฆ yes. the synopsis is the thing itself. minimalist queen behavior, no notes. ๐Ÿ‘‘

๐ŸŒธ DESCRIPTION ๐ŸŒธ

bestie. listen. the system call is the fundamental interface between an application and the Linux kernel. that's not me being dramatic, that's literally the words. it's the doorway. the connection. the way your little program gets to whisper to the kernel and have the kernel actually do something about it. ๐Ÿซถ


๐ŸŽ€ System calls and library wrapper functions ๐ŸŽ€

okay so here's the tea: syscalls are generally not invoked directly โ€” you go through wrapper functions in glibc (or maybe some other library, we don't gatekeep). wanna know about direct invocation? that's a whole other vibe, go read intro(2). ๐Ÿ“–

often โ€” but not always, ok don't @ me โ€” the wrapper function's name is exactly the same as the name of the system call it invokes. example: glibc has a function chdir() which invokes the underlying "chdir" system call. same name, different layer, so cute. โœจ

and often the glibc wrapper is thin โ€” like, it does barely any work other than copying arguments to the right registers before invoking the system call, and then setting errno appropriately after the system call has returned. (fun fact: these are the exact same steps performed by syscall(2), which you can use to invoke system calls that have no wrapper function at all. icon behavior.) ๐ŸŽ€

okay this part matters so pay attention bestie: system calls indicate a failure by returning a negative error number to the caller on architectures without a separate error register/flag, as noted in syscall(2). when that happens, the wrapper function negates the returned error number (to make it positive), copies it to errno, and returns -1 to the caller of the wrapper. that's the failure pipeline. that's the lore. ๐Ÿ˜ญ

sometimes though, the wrapper function does extra work before invoking the system call. example: nowadays there are (for reasons described below, we'll get there) two related system calls, truncate(2) and truncate64(2), and the glibc truncate() wrapper function checks which of those system calls are provided by the kernel and determines which should be employed. it's a whole matchmaking situation. ๐Ÿ’…


๐ŸŒˆ System call list ๐ŸŒˆ

below is a list of the Linux system calls. in that list, the Kernel column tells you the kernel version for those system calls that were new in Linux 2.2, or have appeared since that kernel version. ๐Ÿ“‹

note the following points, bestie, because the version-column lore is REAL:

  • where no kernel version is indicated, the system call appeared in Linux 1.0 or earlier. ancient. vintage. the elders. ๐Ÿงš
  • where a system call is marked "1.2" this means the system call probably appeared in a Linux 1.1.x kernel version, and first appeared in a stable kernel with 1.2. (development of the Linux 1.2 kernel was initiated from a branch of Linux 1.0.6 via the Linux 1.1.x unstable kernel series.) ๐Ÿ“
  • where a system call is marked "2.0" this means the system call probably appeared in a Linux 1.3.x kernel version, and first appeared in a stable kernel with Linux 2.0. (development of the Linux 2.0 kernel was initiated from a branch of Linux 1.2.x, somewhere around Linux 1.2.10, via the Linux 1.3.x unstable kernel series.) โœจ
  • where a system call is marked "2.2" this means the system call probably appeared in a Linux 2.1.x kernel version, and first appeared in a stable kernel with Linux 2.2.0. (development of the Linux 2.2 kernel was initiated from a branch of Linux 2.0.21 via the Linux 2.1.x unstable kernel series.) ๐Ÿ’œ
  • where a system call is marked "2.4" this means the system call probably appeared in a Linux 2.3.x kernel version, and first appeared in a stable kernel with Linux 2.4.0. (development of the Linux 2.4 kernel was initiated from a branch of Linux 2.2.8 via the Linux 2.3.x unstable kernel series.) ๐Ÿ’–
  • where a system call is marked "2.6" this means the system call probably appeared in a Linux 2.5.x kernel version, and first appeared in a stable kernel with Linux 2.6.0. (development of Linux 2.6 was initiated from a branch of Linux 2.4.15 via the Linux 2.5.x unstable kernel series.) ๐Ÿฆ‹
  • starting with Linux 2.6.0, the development model changed, and new system calls may appear in each Linux 2.6.x release. in this case, the exact version number where the system call appeared is shown. this convention continues with the Linux 3.x kernel series, which followed on from Linux 2.6.39; and the Linux 4.x kernel series, which followed on from Linux 3.19; and the Linux 5.x kernel series, which followed on from Linux 4.20; and the Linux 6.x kernel series, which followed on from Linux 5.19. so many series. so many follow-ons. the lineage is unbroken. ๐Ÿ‘‘
  • in some cases, a system call was added to a stable kernel series after it branched from the previous stable kernel series, and then backported into the earlier stable kernel series. for example some system calls that appeared in Linux 2.6.x were also backported into a Linux 2.4.x release after Linux 2.4.15. when this is so, the version where the system call appeared in both of the major kernel series is listed. double-dipping, but make it versioning. ๐Ÿ’…

and now for the main event, the list of system calls that are available as at Linux 5.14 (or in a few cases only on older kernels) is as follows: ๐ŸŒŸ

okay so the big list continues and it's giving encyclopedia energy ๐Ÿ’… every syscall, every kernel debut, every little footnote โ€” no cap, it's all here.


okay so one last thing before we move on, bestie, because it's important and it's giving "plot twist" ๐Ÿ’…

On a bunch of platforms โ€” x86-32 included โ€” all the socket calls are multiplexed (through glibc wrapper functions, no less) via socketcall(2). And in the same way, the System V IPC calls are multiplexed through ipc(2). So when you see "see the notes on socketcall(2)" or "see the notes on ipc(2)" up there, that's the whole tea ๐Ÿซ–โœจ

okay so real talk: the kernel's system call table has slots reserved for a whole bunch of calls that just... never showed up. They're in the table, bestie, but they are not implemented in the standard kernel:

(also see unimplemented(2) โ€” it's giving "the graveyard, but make it documentation" ๐Ÿชฆ)

BUT plot twist: ftime(3), profil(3), and ulimit(3) do exist as library routines, so you're not fully abandoned. ๐Ÿซถ

The slot for phys(2) is in use since Linux 2.1.116 โ€” it got taken over by umount(2), and phys(2) will never be implemented. Periodt. The getpmsg(2) and putpmsg(2) calls are for kernels patched to support STREAMS, and they may never be in the standard kernel either. ๐Ÿ™ˆ

There was briefly set_zone_reclaim(2), added in Linux 2.6.13 and removed in Linux 2.6.16 โ€” this system call was never available to user space. It was a whole main character for like five minutes. ๐Ÿ’€

โœจ System calls on removed ports โœจ

Some system calls only ever existed on Linux architectures that have since been removed from the kernel. Like, gone gone. ๐Ÿฆ‹

Blackfin (port removed in Linux 4.17)

  • bfin_spinlock(2) (added in Linux 2.6.22)
  • dma_memcpy(2) (added in Linux 2.6.22)
  • sram_alloc(2) (added in Linux 2.6.22)
  • sram_free(2) (added in Linux 2.6.22)

Metag (port removed in Linux 4.17)

  • metag_get_tls(2) (added in Linux 3.9)
  • metag_set_fpu_flags(2) (added in Linux 3.9)
  • metag_set_tls(2) (added in Linux 3.9)
  • metag_setglobalbit(2) (added in Linux 3.9)

Tile (port removed in Linux 4.17)

  • cmpxchg_badaddr(2) (added in Linux 2.6.36)

๐Ÿ“ NOTES ๐Ÿ“

Roughly speaking (roughly, babes, don't come for me), the code belonging to the system call with number __NR_xxx defined in /usr/include/asm/unistd.h can be found in the Linux kernel source in the routine sys_xxx(). There are many exceptions, however โ€” mostly because older system calls were superseded by newer ones, and this has been treated somewhat unsystematically. ikr. ๐Ÿ˜ญ On platforms with proprietary operating-system emulation, such as sparc, sparc64, and alpha, there are many additional system calls; mips64 also contains a full set of 32-bit system calls.

Over time, changes to the interfaces of some system calls have been necessary. One reason for such changes was the need to increase the size of structures or scalar values passed to the system call. Because of these changes, certain architectures (notably, longstanding 32-bit architectures such as i386) now have various groups of related system calls (e.g., truncate(2) and truncate64(2)) which perform similar tasks, but which vary in details such as the size of their arguments. (As noted earlier, applications are generally unaware of this: the glibc wrapper functions do some work to ensure that the right system call is invoked, and that ABI compatibility is preserved for old binaries.) ๐Ÿ’…

Examples of system calls that exist in multiple versions are the following:

  • By now there are three different versions of stat(2): sys_stat() (slot __NR_oldstat), sys_newstat() (slot __NR_stat), and sys_stat64() (slot __NR_stat64), with the last being the most current. A similar story applies for lstat(2) and fstat(2).
  • Similarly, the defines __NR_oldolduname, __NR_olduname, and __NR_uname refer to the routines sys_olduname(), sys_uname(), and sys_newuname().
  • In Linux 2.0, a new version of vm86(2) appeared, with the old and the new kernel routines being named sys_vm86old() and sys_vm86().
  • In Linux 2.4, a new version of getrlimit(2) appeared, with the old and the new kernel routines being named sys_old_getrlimit() (slot __NR_getrlimit) and sys_getrlimit() (slot __NR_ugetrlimit).
  • Linux 2.4 increased the size of user and group IDs from 16 to 32 bits. To support this change, a range of system calls were added (e.g., chown32(2), getuid32(2), getgroups32(2), setresuid32(2)), superseding earlier calls of the same name without the "32" suffix.
  • Linux 2.4 added support for applications on 32-bit architectures to access large files (i.e., files for which the sizes and file offsets can't be represented in 32 bits). To support this change, replacements were required for system calls that deal with file offsets and sizes. Thus the following system calls were added: fcntl64(2), getdents64(2), stat64(2), statfs64(2), truncate64(2), and their analogs that work with file descriptors or symbolic links. These system calls supersede the older system calls which, except in the case of the "stat" calls, have the same name without the "64" suffix.

On newer platforms that only have 64-bit file access and 32-bit UIDs/GIDs (e.g., alpha, ia64, s390x, x86-64), there is just a single version of the UID/GID and file access system calls. On platforms (typically, 32-bit platforms) where the *64 and *32 calls exist, the other versions are obsolete.

  • The rt_sig* calls were added in Linux 2.2 to support the addition of real-time signals (see signal(7)). These system calls supersede the older system calls of the same name without the "rt_" prefix.
  • The select(2) and mmap(2) system calls use five or more arguments, which caused problems in the way argument passing on the i386 used to be set up. Thus, while other architectures have sys_select() and sys_mmap() corresponding to __NR_select and __NR_mmap, on i386 one finds old_select() and old_mmap() (routines that use a pointer to an argument block) instead. These days passing five arguments is not a problem any more, and there is a __NR__newselect that corresponds directly to sys_select() and similarly __NR_mmap2. s390x is the only 64-bit architecture that has old_mmap(). the way that history lingers... iconic honestly ๐Ÿ‘‘

๐Ÿฆ‹ Architecture-specific details: Alpha ๐Ÿฆ‹

  • getxgid(2) โ€” returns a pair of GID and effective GID via registers r0 and r20; it is provided instead of getgid(2) and getegid(2). two for one, we love efficiency โœจ
  • getxpid(2) โ€” returns a pair of PID and parent PID via registers r0 and r20; it is provided instead of getpid(2) and getppid(2).
  • old_adjtimex(2) โ€” is a variant of adjtimex(2) that uses struct timeval32, for compatibility with OSF/1.
  • getxuid(2) โ€” returns a pair of UID and effective UID via registers r0 and r20; it is provided instead of getuid(2) and geteuid(2).
  • sethae(2) โ€” is used for configuring the Host Address Extension register on low-cost Alphas in order to access address space beyond first 27 bits.

๐ŸŒˆ SEE ALSO ๐ŸŒˆ


and that's a wrap on the whole page, bestie!! ๐ŸŽ€ This one's from Linux man-pages 6.20, dated 2026-02-08 โ€” go forth and syscall responsibly, mwah ๐Ÿ’–๐ŸŒธ๐Ÿซถ

๐Ÿ“ฆ where this page comes from
  • arch rolling: man-pages 6.20-1 ยท BSD-2-Clause AND BSD-3-Clause AND BSD-4.3TAHOE AND BSD-4-Clause-UC AND GPL-1.0-or-later AND GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-or-later AND LGPL-3.0-linking-exception AND LGPL-3.0-or-later AND LicenseRef-Public-Domain AND LicenseRef-UltraPermissive AND Linux-man-pages-1-para AND Linux-man-pages-copyleft AND Linux-man-pages-copyleft-2-para AND Linux-man-pages-copyleft-var AND MIT AND Spencer-94
  • nixpkgs unstable: man-pages 6.20
  • ๐Ÿ“œ the page's license: Linux-man-pages-copyleft
  • ๐Ÿ’– girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms