syscall.sh refresh covers every Linux syscall across 27 architectures, kernel 3.3 onward

An updated reference with full kernel history

The developer behind syscall.sh has overhauled the site and its accompanying API, announcing the refresh in a "Show HN" post on Hacker News. The reference documents Linux system calls across 27 CPU architectures, spanning kernel releases from 3.3 up to 7.3, and for every entry it records both the release in which the call first appeared and, where relevant, the release that removed it.

What the tables contain

For each architecture, the table lists every syscall number along with its arguments and registers. The mainstream targets are all there — x86-64 with 369 syscalls, 32-bit i386 with 441, AArch64 with 326, 32-bit ARM with 426 and 64-bit RISC-V with 327 — and compatibility ABIs such as ia32 and x32 on x86-64, plus the three MIPS ABIs (o32, n32 and n64), get their own tables. Legacy machines including DEC Alpha, Motorola 68000, HP PA-RISC and SuperH are covered, as are embedded cores from ARC, C-SKY, Hexagon, MicroBlaze, Nios II, OpenRISC and Xtensa, alongside newer ports such as LoongArch64 and IBM Z.

Scan depth varies by target, according to the site: x86-64 data reaches back to kernel 3.3, AArch64 to 3.7, ARM to 4.10, RISC-V to 4.15 and LoongArch64 to 5.19. The site flags one caveat explicitly — a syscall whose first-seen release matches the earliest kernel scanned for its architecture may well be older than that.

History, JSON and the API

Each architecture page carries a kernel selector, so the table can be viewed as it stood in any given release, and a "with removed" option keeps retired entries visible, marked with the release that dropped them. The complete table — appearance and removal fields included — is available as a plain JSON file per architecture. On top of that sits a versioned API at api.syscall.sh that can serve a single syscall's details, such as read on x86-64, for any kernel release, along with diffs between releases.

Calling conventions included

The tables also document each architecture's calling convention: the instruction that traps into the kernel, the register carrying the syscall number, the six argument registers and the register where the return value lands. On x86-64 that means the syscall instruction, the number in rax, arguments in rdi, rsi, rdx, r10, r8 and r9, and the result back in rax. On IBM Z the entry is svc 0 with the number in r1 and arguments in r2 through r7, while 32-bit x86 enters via int 0x80 with the number in eax.

Where the data comes from

According to the site, everything is generated from the kernel source itself: a generator walks each architecture's syscall table and its SYSCALL_DEFINE macros for every mainline release it scans, so the numbers reflect the kernel's own dispatch tables rather than hand-maintained lists. Short descriptions come from the Linux man-pages project, with io_uring descriptions sourced from liburing, and the site is rebuilt from the API whenever the underlying data changes.

Why it matters

Syscall numbers are not portable: the same call carries a different number on nearly every architecture, and arguments travel through different registers via different entry instructions. Anyone writing low-level code, building emulators or seccomp policies, porting software to a new target, or reverse-engineering binaries benefits from a single accurate cross-reference. Because the data is machine-readable, versioned by kernel release and free to fetch through an API, it can feed tooling rather than serve only as a browsing aid. The removal history is a bonus for anyone supporting older software, since retired syscalls stay documented instead of vanishing from view.