From nobody Wed Sep 22 13:42:30 2021 X-Original-To: freebsd-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 6A3E61759CF1 for ; Wed, 22 Sep 2021 13:42:37 +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 4HDzxn0zKSz3MCR; Wed, 22 Sep 2021 13:42:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 18MDgUYU030582 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 22 Sep 2021 16:42:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 18MDgUYU030582 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 18MDgUic030581; Wed, 22 Sep 2021 16:42:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 22 Sep 2021 16:42:30 +0300 From: Konstantin Belousov To: Damjan Jovanovic Cc: Alan Somers , FreeBSD CURRENT Subject: Re: Using modern APIs in Rust on FreeBSD Message-ID: References: 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=us-ascii Content-Disposition: inline In-Reply-To: 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=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HDzxn0zKSz3MCR X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Sep 22, 2021 at 06:27:09AM +0200, Damjan Jovanovic wrote: > On Wed, Sep 22, 2021 at 6:08 AM Alan Somers wrote: > > > tldr; should the Rust ecosystem ditch FreeBSD 10 compat for new code? > > > > Rust uses FFI to talk to the OS's C library. That makes cross-compiling a > > breeze. Unfortunately, it also fossilizes the ABI. FreeBSD's libc makes > > careful use of ELF symbol versioning. That's how we were able to change > > ino_t to 64-bits while maintaining backwards-compatibility with old > > binaries, for example. But the Rust toolchain isn't able to take > > advantage. Right now, the toolchain uses a FreeBSD 10 ABI, and the libc > > crate (which virtually all crates depend on) uses a FreeBSD 11 ABI. > > > > How exactly is the ABI fossilized? If Rust's FFI uses run-time dynamic > linking, it should be able to use dlvsym() to access the correct version of > libc symbols. No, FFI does not use dynamic linking in dynamic sense, i.e. it does not utilize dlopen/dlsym. Rust directly calls into extern "C" functions, and this is quite useful feature, because using dlsym for everything you need from system libraries is beyond the pain point. Rust can link to specific version of the symbol, and libc uses this feature, like this: #[cfg_attr(all(target_os = "freebsd", freebsd11), link_name = "statfs@FBSD_1.0")] pub fn statfs(path: *const ::c_char, buf: *mut statfs) -> ::c_int; There it requests pre-ino64 statfs(). More, libc already has configurations for freebsd11 and later, as can be seen from the citation above. And I see nothing that would prevent libc from defining freebsd11 and freebsd12 variants of struct stat, struct statfs, struct dirent, and so on. That said, I definitely do not want spend (more) time on this. Due to the way libc is structured, to make an impression that definitions are shared between different *BSDs, it is extremely painful to add new bindings and not break other BSDs. I tried something as simple as adding missing MNT_XXX constants for mnt_flags and gave up after full day when I realized that I have to test on Net/Open/DragonflyBSD as well.