I don't know where you draw your lines, but a syscall (on Linux and amd64, but it should work pretty much the same on BSD and other architectures) looks like

I don't know where you draw your lines, but a syscall (on Linux and amd64, but it should work pretty much the same on BSD and other architectures) looks like mov rax, <syscall number> ; Depending on the syscall, it expects its parameters ; in various other registers syscall ; this is an actual instruction So yes, it is very much part of the ABI. It selects which function to call. The extra indirection, AFAIK, is needed because you couldn't just call a kernel function from userspace and have it run with kernel privileges. That's what the syscall instruction is for, to put the processor back in ring 0 so the syscall handler runs in kernel space. As for what's lost, well, for example, a sane language-agnostic kernel ABI is lost to a C-centric libc API. I don't know if the syscall wrapper support in libc is as incomplete on BSD as it is on Linux, but they could add the missing wrappers, of course. A cleaner approach might have been to have a separate libsyscall that only wraps syscalls and is mapped into the "blessed" address space that is allowed to issue syscalls. But then libc would have to wrap the wrappers, and they probably didn't want that extra indirection.