Re: libc/libsys split coming soon

On Sat, Feb 3, 2024, 11:02 AM Konstantin Belousov <kostikbel@gmail.com>
wrote:

> On Sat, Feb 03, 2024 at 11:05:10AM -0500, Daniel Eischen wrote:
> > Will this break binary compatibility with older programs expecting those
> symbols in libc and not linked to libsys?
>
> As was mentioned, libc filters libsys.  This means that libc exports all
> the same symbols as before, but forward the implementation to libsys.
> For apps nothing changes, the introduction of libsys is (should be) ABI
> compatible.
>
> More, I would state that no binaries wanting to state binary-compatble
> with future FreeBSD should link to libsys directly, at least for now.
>

How do you view Golang or Rust run times using this then? They try to avoid
libc today.

Warner

Warner

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