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>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000009d1e9706107e2491 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Feb 3, 2024, 11:02=E2=80=AFAM 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 thos= e > 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=E2=80=AFAM, Dave Cottlehuber <dch@skunkwerks.= at> > wrote: > > > > > > =EF=BB=BFOn 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 seri= es > > >> of patches which moves system calls, vdso support, and libc's parsin= g > 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 fo= r > > >> 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=E2=80=99s the appropriate mechanism for such a language to know = which > version of FreeBSD it=E2=80=99s talking to, to ensure syscall table match= es 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 > > > > > > > > > > > > --0000000000009d1e9706107e2491 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Sat, Feb 3, 2024, 11:02=E2=80=AFAM Konstantin Belou= sov <<a href=3D"mailto:kostikbel@gmail.com">kostikbel@gmail.com</a>> = wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e= x;border-left:1px #ccc solid;padding-left:1ex">On Sat, Feb 03, 2024 at 11:0= 5:10AM -0500, Daniel Eischen wrote:<br> > Will this break binary compatibility with older programs expecting tho= se symbols in libc and not linked to libsys?<br> <br> As was mentioned, libc filters libsys.=C2=A0 This means that libc exports a= ll<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=3D"auto"><br></div><div dir=3D"auto">How do= you view Golang or Rust run times using this then? They try to avoid libc = today.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Warner</div><div = dir=3D"auto"><br></div><div dir=3D"auto">Warner</div><div dir=3D"auto"><div= class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 = 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > <br> > > On Feb 3, 2024, at 3:39=E2=80=AFAM, Dave Cottlehuber <<a href= =3D"mailto:dch@skunkwerks.at" target=3D"_blank" rel=3D"noreferrer">dch@skun= kwerks.at</a>> wrote:<br> > > <br> > > =EF=BB=BFOn Fri, 2 Feb 2024, at 23:31, Brooks Davis wrote:<br> > >> TL;DR: The implementation of system calls is moving to a sepe= rate<br> > >> library (libsys).=C2=A0 No changes are required to existing s= oftware (except<br> > >> to ensure that libsys is present when building custom disk im= ages).<br> > >> <br> > >> Code: <a href=3D"https://github.com/freebsd/freebsd-src/pull/= 908" rel=3D"noreferrer noreferrer" target=3D"_blank">https://github.com/fre= ebsd/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&#= 39;s parsing of<br> > >> the ELF auxiliary argument vector into a separate library (li= bsys).=C2=A0 I<br> > >> plan to do this early next week (February 5th).<br> > >> <br> > >> This change serves three primary purposes:<br> > >>=C2=A0 1. It's easier to completely replace system call im= plementations for<br> > >>=C2=A0 =C2=A0 =C2=A0tracing or compartmentalization purposes.<= br> > >>=C2=A0 2. It simplifies the implementation of restrictions on = system calls such<br> > >>=C2=A0 =C2=A0 =C2=A0as those implemented by OpenBSD's msys= call(2)<br> > >>=C2=A0 =C2=A0 =C2=A0(<a href=3D"https://man.openbsd.org/msysca= ll.2" rel=3D"noreferrer noreferrer" target=3D"_blank">https://man.openbsd.o= rg/msyscall.2</a>).<br> > >>=C2=A0 3. It allows language runtimes to link with libsys for = system call<br> > >>=C2=A0 =C2=A0 =C2=A0implementations 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=E2=80=99s the appropriate mechanism for such a language to k= now which version of FreeBSD it=E2=80=99s talking to, to ensure syscall tab= le matches the languages expectations?<br> > > <br> > > It would be nice to hear about any experiments in (2) and how tha= t compares to things such as capsicum.<br> > > <br> > > [1]: <a href=3D"https://github.com/ziglang/zig/issues/165" rel=3D= "noreferrer noreferrer" target=3D"_blank">https://github.com/ziglang/zig/is= sues/165</a><br> > > <br> > > A+<br> > > Dave<br> > > <br> > > <br> > <br> > <br> <br> </blockquote></div></div></div> --0000000000009d1e9706107e2491--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoYcJA0QB5EcTsrm1D6n9g9KZ_Xnc84rW4OpQKQxeLCxw>