Show HN: I've updated my Linux System Call website and API
- ID
- 42235
- Status
- summarized
- Published
- 02 Nov 2026, 5:29 PM
- Fetched
- 03 Nov 2026, 7:45 AM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://syscall.sh/
- Source URL
- https://hnrss.org/best
Summary
- Score
- 5.5
- Created
- 03 Nov 2026, 7:46 AM
- Tags
- Audience
- developersvibe_coders
What happened
syscall.sh is a Show HN site that puts every Linux syscall table in one place: 27 architectures with syscall numbers, arguments and registers, from Linux 3.3 onward (the page states coverage up to 7.3). Each table is also a plain JSON file at /<arch>/syscalls.json, and there is a versioned API — e.g. curl https://api.syscall.sh/v2/syscalls/x64/read — with diffs between kernel releases. It also tabulates calling conventions per arch (NR, ARG0–ARG5, RETURN), and the per-arch counts vary widely: x64 369 syscalls since 3.3, x86 441, arm64 326 since 3.7, riscv64 327 since 4.15, m68k 435.
Why it matters
If you write seccomp filters, parse strace output, or cross-compile tooling for arm64/riscv64 targets from an x86 machine, you can now pull syscall numbers from the JSON instead of grepping kernel headers. The 'since kernel X' metadata is the practical part: it tells you whether a syscall exists on your target kernel — riscv64 starts at 4.15, loongarch64 at 5.19, arm EABI at 4.10 — so you avoid shipping a filter or probe that references a number absent on the deployed kernel. Treat the stated upper bound of 'Linux 7.3' with suspicion until you verify against the API, since the table's authority is the only thing making it useful.
Discussion angle
Ask who in the room has actually hand-written a seccomp filter or parsed strace across architectures, and whether they'd trust a community-maintained syscall table over the kernel headers in their own toolchain — then test one number live against /x64/syscalls.json and the kernel source.