Date: Sat, 3 Feb 2024 11:10:14 -0700 From: Warner Losh <imp@bsdimp.com> To: Konstantin Belousov <kostikbel@gmail.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: <CANCZdfoYcJA0QB5EcTsrm1D6n9g9KZ_Xnc84rW4OpQKQxeLCxw@mail.gmail.com> In-Reply-To: <Zb5_j8X0AichbQi6@kib.kiev.ua> References: <458c2a3b-1139-4449-a4a9-f23782686dea@app.fastmail.com> <082DBB76-B8B0-4583-BDE4-B6DCD1DAD133@vigrid.com> <Zb5_j8X0AichbQi6@kib.kiev.ua>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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 > > > > > > > > > > > > [-- Attachment #2 --] <div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 3, 2024, 11:02 AM Konstantin Belousov <<a href="mailto:kostikbel@gmail.com">kostikbel@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Feb 03, 2024 at 11:05:10AM -0500, Daniel Eischen wrote:<br> > Will this break binary compatibility with older programs expecting those symbols in libc and not linked to libsys?<br> <br> As was mentioned, libc filters libsys. This means that libc exports all<br> the same symbols as before, but forward the implementation to libsys.<br> For apps nothing changes, the introduction of libsys is (should be) ABI<br> compatible.<br> <br> More, I would state that no binaries wanting to state binary-compatble<br> with future FreeBSD should link to libsys directly, at least for now.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">How do you view Golang or Rust run times using this then? They try to avoid libc today.</div><div dir="auto"><br></div><div dir="auto">Warner</div><div dir="auto"><br></div><div dir="auto">Warner</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > <br> > > On Feb 3, 2024, at 3:39 AM, Dave Cottlehuber <<a href="mailto:dch@skunkwerks.at" target="_blank" rel="noreferrer">dch@skunkwerks.at</a>> wrote:<br> > > <br> > > On Fri, 2 Feb 2024, at 23:31, Brooks Davis wrote:<br> > >> TL;DR: The implementation of system calls is moving to a seperate<br> > >> library (libsys). No changes are required to existing software (except<br> > >> to ensure that libsys is present when building custom disk images).<br> > >> <br> > >> Code: <a href="https://github.com/freebsd/freebsd-src/pull/908" rel="noreferrer noreferrer" target="_blank">https://github.com/freebsd/freebsd-src/pull/908</a><br>; > >> <br> > >> After nearly a decade of intermittent work, I'm about to land a series<br> > >> of patches which moves system calls, vdso support, and libc's parsing of<br> > >> the ELF auxiliary argument vector into a separate library (libsys). I<br> > >> plan to do this early next week (February 5th).<br> > >> <br> > >> This change serves three primary purposes:<br> > >> 1. It's easier to completely replace system call implementations for<br> > >> tracing or compartmentalization purposes.<br> > >> 2. It simplifies the implementation of restrictions on system calls such<br> > >> as those implemented by OpenBSD's msyscall(2)<br> > >> (<a href="https://man.openbsd.org/msyscall.2" rel="noreferrer noreferrer" target="_blank">https://man.openbsd.org/msyscall.2</a>).<br>; > >> 3. It allows language runtimes to link with libsys for system call<br> > >> implementations without requiring libc.<br> > > <br> > > Awesome! So (3) is generally considered ideal for languages like zig[1], rust or go, to use directly?<br> > > <br> > > 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?<br> > > <br> > > It would be nice to hear about any experiments in (2) and how that compares to things such as capsicum.<br> > > <br> > > [1]: <a href="https://github.com/ziglang/zig/issues/165" rel="noreferrer noreferrer" target="_blank">https://github.com/ziglang/zig/issues/165</a><br>; > > <br> > > A+<br> > > Dave<br> > > <br> > > <br> > <br> > <br> <br> </blockquote></div></div></div>help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoYcJA0QB5EcTsrm1D6n9g9KZ_Xnc84rW4OpQKQxeLCxw>