24 ms·

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

• kstrauser 3y ago
  Is that different from Linux/Mac/etc?
  • masklinn 3y ago
    It is not different on mac (although there libc is just a subset of the wider libSystem). It is different, uniquely so, on linux: on most unices the kernel and libc are developed as two sides of an entire system, both being updated in lockstep when the system is updated. As such there is no real concern about keeping the syscalls stable, if you need to change it on the kernel side you update it to match on the libc side and you're done, everybody is supposed to use the libc. Not so on linux, the kernel and the libc (most commonly glibc) are developed by entirely different groups which don't necessarily like or communicate with one another. As a result, on linux syscalls are a stable API, and direct syscalls are an officially supported method of interaction. In fact its sometimes necessary as the libc might decide not to expose a syscall.
    • kstrauser 3y ago
      Thanks for that. So although the name is "libc", it's more like "lib-how-to-use-the-kernel", too?
      • masklinn 3y ago
        Yes, for historical reasons it bunches syscalls (section 2) and C library functions (section 3) into a single binary.
    • LegionMammal978 3y ago
      > It is different, uniquely so, on linux: on most unices the kernel and libc are developed as two sides of an entire system, both being updated in lockstep when the system is updated. Do FreeBSD [0] and NetBSD [1] not fall under "most unices"? They similarly retain backward compatibility in their syscall interface, so that old binaries with old libcs can run on newer kernels. Linux does not stand alone here. [0] https://wiki.freebsd.org/AddingSyscalls#Backward_compatibily https://wiki.freebsd.org/AddingSyscalls#Backward_compatibily [1] https://www.netbsd.org/docs/internals/en/chap-processes.html#syscall_versioning https://www.netbsd.org/docs/internals/en/chap-processes.html...
• masklinn 3y ago
  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.
  • vlovich123 3y ago
    Except notably Linux where the kernel ABI is the thing that’s stable.
    • mikepavone 3y ago
      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.
      • vlovich123 3y ago
        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.
        • mikepavone 3y ago
          Ah sorry, I misunderstood
          • vlovich123 3y ago
            No worries. My wording was muddled.
        • dfox 3y ago
          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”.