zlacker

[return to "OpenBSD: Removing syscall(2) from libc and kernel"]
1. kstrau+ks[view] [source] 2023-10-27 17:34:50
>>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?
◧◩
2. monoca+Gs[view] [source] 2023-10-27 17:36:35
>>kstrau+ks
It's that libc is considered the stable interface for userland in general on openbsd.
◧◩◪
3. kstrau+3t[view] [source] 2023-10-27 17:38:05
>>monoca+Gs
Is that different from Linux/Mac/etc?
◧◩◪◨
4. maskli+It[view] [source] 2023-10-27 17:42:00
>>kstrau+3t
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.

◧◩◪◨⬒
5. kstrau+Rv[view] [source] 2023-10-27 17:52:48
>>maskli+It
Thanks for that. So although the name is "libc", it's more like "lib-how-to-use-the-kernel", too?
◧◩◪◨⬒⬓
6. maskli+Gz[view] [source] 2023-10-27 18:10:14
>>kstrau+Rv
Yes, for historical reasons it bunches syscalls (section 2) and C library functions (section 3) into a single binary.
[go to top]