Will this break binary compatibility with older programs expecting those symbols in libc and not linked to libsys?
> On Feb 3, 2024, at 3:39 AM, Dave Cottlehuber <d...@skunkwerks.at> wrote: > > 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 > >
