Date: Sat, 3 Feb 2024 20:33:11 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Daniel Eischen <eischen@vigrid.com>, Brooks Davis <brooks@freebsd.org>, FreeBSD Current <current@freebsd.org>, Dave Cottlehuber <dch@skunkwerks.at> Subject: Re: libc/libsys split coming soon Message-ID: <Zb6G5ySxpVFSuppE@kib.kiev.ua> In-Reply-To: <CANCZdfoYcJA0QB5EcTsrm1D6n9g9KZ_Xnc84rW4OpQKQxeLCxw@mail.gmail.com> References: <458c2a3b-1139-4449-a4a9-f23782686dea@app.fastmail.com> <082DBB76-B8B0-4583-BDE4-B6DCD1DAD133@vigrid.com> <Zb5_j8X0AichbQi6@kib.kiev.ua> <CANCZdfoYcJA0QB5EcTsrm1D6n9g9KZ_Xnc84rW4OpQKQxeLCxw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 03, 2024 at 11:10:14AM -0700, Warner Losh wrote: > 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. Goland runtime issues syscalls directly (using CPU instructions). I believe this is true even when Go-compiled binary is linked against libc to provide C FFI. Rust does use libc to get system services. No changes there. Or, is you question about switching Go and Rust to directly using libsys? Then Rust does not need that. For Go, indeed, using either libc or libsys instead of static linking and directly issuing syscalls would be better. Right now Go binary needs to understand all small details in the difference between C wrappers ABI and real syscalls. Also they re-wrote e.g. the gettime() code from vdso into their runtime. > > 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 > > > > > > > > > > > > > > > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Zb6G5ySxpVFSuppE>