> I find sysctl(3) in OpenBSD 6.2 is changed to system call in -current
> (please refer the manual: https://man.openbsd.org/sysctl.2).
> So the sysctl would be a system call instead of library function in
> future OpenBSD?
> Thanks in advance!
> Best Regards
> Nan Xiao
On Mon, Mar 12, 2018 at 7:52 PM, Theo de Raadt <[hidden email]> wrote:
> It is a library routine that calls a system call.
> It isn't worth changing at this point.
Actually we did.
> > I find sysctl(3) in OpenBSD 6.2 is changed to system call in -current
> > (please refer the manual: https://man.openbsd.org/sysctl.2).
> > So the sysctl would be a system call instead of library function in
> > future OpenBSD?
Back when sysctl() supported the CTL_USER branch of MIB, the function in
libc had non-trivial logic. At some point I deleted the CTL_USER support
reducing it just a trivial wrapper around the ASM that did the syscall, and
then we deleted the shim and just made it the ASM shim directly like many
of the other syscalls.
...but don't read too much into the section 2 vs section 3 distinction.
For example, consider the first six syscalls: exit, fork, read, write,
open, close. *None* of those are bare ASM shims; *all* of them have
non-trivial wrappers in libc! exit(3) is widely acknowledged as such and
_exit(2) is provided for direct access to the syscall, but we're not going
to rename the manpages for the others just to reflect that fork(2) handles
pthread_atfork() registrations, and the other four do pthread cancellation
At this point section 2 mean, uh, "you may see this in kdump output"?