Re: libc/libsys split coming soon

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 <dch@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
> 
>