zlacker

>>eclipt+(OP)
I don't know a lot about this corner of the OS. Why are syscalls in libc, instead of something like a libsyscall? I could see why a language might want not to depend on what's at least notionally the C runtime. Is the fact that the kernel interface is in libc an accident of Unix being written in C, or is there something more fundamental there?

>>kstrau+ks
It's that libc is considered the stable interface for userland in general on openbsd.

>>monoca+Gs
In pretty much every OS of the unix tradition. libc is the API, with a stable ABI. Although Windows has a something pretty much identical in — I believe — ntdll. The name and API differ, but the intent is the same.

>>maskli+kt
Except notably Linux where the kernel ABI is the thing that’s stable.

>>vlovic+ev
glibc actually goes through quite a bit of effort to remain backwards compatible. There have been times when mistakes were made here, but the extent to which glibc does not have a stable ABI is overstated. The only annoying thing about glibc and ABI stability is that the way it achieves that is via symbol versioning which makes it annoying to target an old glibc on a system with a new er glibc.

>>mikepa+Gx
I didn’t mean to imply that glibc’s API isn’t stable. Just that the stable API boundary for the kernel on Linux is the syscall ABI, not libc.

>>vlovic+wy
Another stable ABI boundary is anything produced by glibc that can be conceivably placed into memory shared by different unrelated processes (ie. Posix IPC primitives). The requirement for backwards compatibility and architecture variant compatibility (32b/64b…) is the largest reason why things like pthread_mutex have somewhat large overhead and why it is worthwhile to invent various iterations of “futex in userspace”.