Re: libc/libsys split coming soon

On Fri, 2 Feb 2024, at 23:31, Brooks Davis wrote:
> TL;DR: The implementation of system calls is moving to a seperate
> library (libsys).  No changes are required to existing software (except
> to ensure that libsys is present when building custom disk images).
>
> Code: https://github.com/freebsd/freebsd-src/pull/908
>
> After nearly a decade of intermittent work, I'm about to land a series
> of patches which moves system calls, vdso support, and libc's parsing of
> the ELF auxiliary argument vector into a separate library (libsys).  I
> plan to do this early next week (February 5th).
>
> This change serves three primary purposes:
>   1. It's easier to completely replace system call implementations for
>      tracing or compartmentalization purposes.
>   2. It simplifies the implementation of restrictions on system calls such
>      as those implemented by OpenBSD's msyscall(2)
>      (https://man.openbsd.org/msyscall.2).
>   3. It allows language runtimes to link with libsys for system call
>      implementations without requiring libc.

Awesome! So (3) is generally considered ideal for languages like zig[1], rust or go, to use directly?

What’s the appropriate mechanism for such a language to know which version of FreeBSD it’s talking to, to ensure syscall table matches the languages expectations?

It would be nice to hear about any experiments in (2) and how that compares to things such as capsicum.

[1]: https://github.com/ziglang/zig/issues/165

A+
Dave