Guide to Linux System Calls (2016) (opens in new tab)

It is absolutely not true on many (most?) operating systems; Linux is actually an outlier, and we mostly forget that it's the odd one out because it's so popular. Off the top of my head, I believe both NT and Solaris define libc as the stable interface that userspace uses; I don't recall exactly what the BSDs do, but I suspect that they at least strongly encourage using libc and not trying to talk to the kernel yourself (IIRC OpenBSD does this because some of their security measures are managed by libc). Go has hit this a few times because they don't want to depend on libc if they can avoid it, but on a lot of systems they really can't avoid it.

Ah, here we go: https://github.com/golang/go/issues/36435

> Upcoming changes to the OpenBSD kernel will prevent system calls from being made unless they are coming from libc.so (with some exceptions, for example, a static binary). There are also likely to be changes to the APIs used for system calls. As such, the Go runtime (and other packages) need to stop using direct syscalls, rather calling into libc functions instead (as has always been done for Solaris and now also for macOS).

(and the "with some exceptions" is why I say "strongly encouraged")

The article is specifically about _Linux_ system calls.

Note that a "syscall" means calling into the kernel directly. Only Linux has stable syscalls.

As mentioned below, on Windows syscalls are highly unstable. They change with every single update to the OS. You have to call functions in ntdll and they in turn will call the kernel. Think of it like a kind of libc but one that must be dynamically linked. You can't statically link it because it's tied to the exact version of Windows you're using.

Of course Window's actual stable interface is the Win32 API, which will call ntdll which in turn makes the syscall.

Well put!