From nobody Sat Feb 03 18:01:51 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TS0pQ3GV3z585qR for ; Sat, 3 Feb 2024 18:02:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TS0pQ08D7z4k8M; Sat, 3 Feb 2024 18:02:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.17.1/8.17.1) with ESMTP id 413I1wGV071980; Sat, 3 Feb 2024 20:02:01 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 413I1wGV071980 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 413I1pum071978; Sat, 3 Feb 2024 20:01:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 3 Feb 2024 20:01:51 +0200 From: Konstantin Belousov To: Daniel Eischen Cc: Brooks Davis , current@freebsd.org, Dave Cottlehuber Subject: Re: libc/libsys split coming soon Message-ID: References: <458c2a3b-1139-4449-a4a9-f23782686dea@app.fastmail.com> <082DBB76-B8B0-4583-BDE4-B6DCD1DAD133@vigrid.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <082DBB76-B8B0-4583-BDE4-B6DCD1DAD133@vigrid.com> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4TS0pQ08D7z4k8M X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] 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. > > > On Feb 3, 2024, at 3:39 AM, Dave Cottlehuber 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 > > > > > >