From nobody Thu Sep 05 01:10:06 2024 X-Original-To: freebsd-hackers@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 4Wzh9l4HH2z5WFTw for ; Thu, 05 Sep 2024 01:10:19 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wzh9l1sl3z4R0Q for ; Thu, 5 Sep 2024 01:10:19 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-xa32.google.com with SMTP id 71dfb90a1353d-4fcfd6b870aso108899e0c.0 for ; Wed, 04 Sep 2024 18:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725498617; x=1726103417; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BIZ89h+PuRX2lUc15IHU5NwgTfFNIb+y2I3sAIQtyas=; b=F6kiIayaXitUjFxybkxNCEmfl35rDeDBxz9nejZBkAB6OGFB7wlwO2eUQUc2x/QxrN gHphg1K08GVgD2hiIRK/lrfn0ESWX1Gzx90ZqDwpjqXP6kf4woms6T4NDSESVBDWtv1I fgzQIlbPFgrj3atPm8QGJkGwHhfS3vC6HHze8OfaQwrc91Az4MyTlDENi07EbzPx7JuS B4acTkhBuCya/K4JMnaoYZSYxYoU/Kd67DYWfE7GHbAT86i96euQCrbKc2SziVWYHyR2 GhucDUmY7DJneswhHjcCfd6l/hHso3xL6I+685ziCAvnbPT6icJLV4F2HmGEIPbXIIat T1Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725498617; x=1726103417; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BIZ89h+PuRX2lUc15IHU5NwgTfFNIb+y2I3sAIQtyas=; b=qzOtD1IVL41Qxbkqs26e/HFwafanWTTITVhYQ4JNIWrJ5DkURV8nxKShewKuJDUVds /lRUJ5OczzD4D19A7Rki4TUJaZMWY23exZ/IVwvHoZNk4vT+2YYhpcwbefsL5Xw4iMGS Cn01ndK1ijaCg/c4zD0HFsH8Pzenv6lIIsEj8vk2Itn7dAYtplHB7D0/mYbJGZ9GnqQr +xhlXVAsIMXl/zPjvHdqjtDsxPs/StoTuSUqYf3iG/M2svoeyB2HBK6lSVfuaeRNNipF uzaawLRkFxcW/reAZNW/Drm2CrooM1cbSVZuWQh0Q1OgqWWMfekuYzW1RKIFSU4mUWdH bhvA== X-Forwarded-Encrypted: i=1; AJvYcCUQp19yPZP0UKAW8ZCPdxOUd91TPwBFC5S6Dkewmn6pGNJzQzDdMjkk/G06EwnbNPrrD1pVt/Ud9KVy7sSZ0jo=@freebsd.org X-Gm-Message-State: AOJu0Yw5F5t5vJL7NXUZR8i2KSW1dsKdm+2FmVMytYvTYCKzDgVbZ/lC UcSIElaMbewq5CNl3VVOiBzf4Y+1ssMqY9i0ebdBgNrb6ZY5YLnq/NqHtjRHaFthSuWMLsDIA/K 4+o0NQeJf0e+g12IV42e+vQ1o0Tr6xFyRRYpWfg== X-Google-Smtp-Source: AGHT+IEICHGde84aE2IT/YZx8vKUXkvyKqfRSuvJ6/CahUUUVFs4A7+Pt7Z7mswbAHElJ/68q5uBd47ij3/CJwZu6xM= X-Received: by 2002:a05:6122:d10:b0:4fc:d9ef:3be6 with SMTP id 71dfb90a1353d-500aad16685mr16294061e0c.2.1725498617194; Wed, 04 Sep 2024 18:10:17 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com> <20240904221522.63E0366@slippy.cwsent.com> In-Reply-To: From: Jacques Fourie Date: Wed, 4 Sep 2024 18:10:06 -0700 Message-ID: Subject: Re: Rust: kernel vs user-space To: Konstantin Belousov Cc: Cy Schubert , Jan Knepper , Mark Delany , freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000243d8b062154f445" 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)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Wzh9l1sl3z4R0Q --000000000000243d8b062154f445 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 4, 2024 at 5:13=E2=80=AFPM Konstantin Belousov wrote: > On Wed, Sep 04, 2024 at 04:43:31PM -0700, Jacques Fourie wrote: > > On Wed, Sep 4, 2024 at 3:41=E2=80=AFPM Konstantin Belousov > > wrote: > > > > > On Wed, Sep 04, 2024 at 03:15:22PM -0700, Cy Schubert wrote: > > > > In message <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com>= , > > > Jan > > > > Kneppe > > > > r writes: > > > > > D > > > > > > > > > > www.dlang.org > > > > > > > > The problem with D is data structure definitions need to also be > > > mirrored > > > > (duplicated) in D. For example, when 64-bit inodes were implemented= D > > > > failed to build and generate any code. The reason for this was > > > > ufs/ufs/inode.h now defined 64-bit inodes while the D representatio= n > as > > > > provided by the D language were still 32-bit. I had opened an issue > with > > > > upstream regarding this. To this day they still haven't figured out > how > > > to > > > > implement 64-bit inodes on newer FreeBSD systems while maintaining > > > 32-bit > > > > inode backward compatibility on older FreeBSD systems (as FreeBSD > > > > implemented this using ifunc). > > > > > > Rust is same. It still uses pre-ino64 bindings for both stdlib and > libc. > > > > > > > Looking at the Rust libc bindings I see the following: > > > https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b= 4eb132/src/unix/bsd/freebsdlike/freebsd/freebsd11/mod.rs#L8 > > > https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b= 4eb132/src/unix/bsd/freebsdlike/freebsd/freebsd12/mod.rs#L5 > > > > Seems to have changed to 64 bit for FreeBSD 12 and up? > > Rust libc seems to make some strange things to follow FreeBSD ABI > evolution, which is not done e.g. for glibc. But anyway, the relevant > place > to look seems to be a comment and decision code at > > https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b= 4eb132/build.rs#L44 > > By default they seems to use FreeBSD 11 ABI from freebsd11 module still. > I do not know what is CARGO_FEATURE_RUSTC_DEP_OF_STD. > > CARGO_FEATURE_RUSTC_DEP_OF_STD is an environment variable set by cargo when libc is built with the rustc-dep-of-std feature, as is done when building the std library. What this means is that the std library uses a libc ABI that is backwards compatible with FreeBSD 12. When using a standalone libc from crates.io you will get libc bindings that are backwards compatible with FreeBSD 11. Definitely not entirely clear to me. I made a small sample app that prints the size of libc::ino_t. Building this app without any environment variables defined results in a size of 4. Building with `LIBC_CI=3D1` results in a size of 8, as does building with `CARGO_FEATURE_RUSTC_DEP_OF_STD=3D1`. These tests were done on a host runni= ng FreeBSD 15. --000000000000243d8b062154f445 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Sep 4, 2024 at 5:13=E2=80=AFP= M Konstantin Belousov <kostikbel@= gmail.com> wrote:
On Wed, Sep 04, 2024 a= t 04:43:31PM -0700, Jacques Fourie wrote:
> On Wed, Sep 4, 2024 at 3:41=E2=80=AFPM Konstantin Belousov <kostikbel@gmail.com&g= t;
> wrote:
>
> > On Wed, Sep 04, 2024 at 03:15:22PM -0700, Cy Schubert wrote:
> > > In message <78BC157F-6E30-49C4-931D-9EB5= 39BD0322@digitaldaemon.com>,
> > Jan
> > > Kneppe
> > > r writes:
> > > > D
> > > >
> > > > www.dlang.org
> > >
> > > The problem with D is data structure definitions need to als= o be
> > mirrored
> > > (duplicated) in D. For example, when 64-bit inodes were impl= emented D
> > > failed to build and generate any code. The reason for this w= as
> > > ufs/ufs/inode.h now defined 64-bit inodes while the D repres= entation as
> > > provided by the D language were still 32-bit. I had opened a= n issue with
> > > upstream regarding this. To this day they still haven't = figured out how
> > to
> > > implement 64-bit inodes on newer FreeBSD systems while maint= aining
> > 32-bit
> > > inode backward compatibility on older FreeBSD systems (as Fr= eeBSD
> > > implemented this using ifunc).
> >
> > Rust is same.=C2=A0 It still uses pre-ino64 bindings for both std= lib and libc.
> >
>
> Looking at the Rust libc bindings I see the following:
> https://github.com/rust-lang/libc/blob= /72c40004a3568849055c0bab5c92c9975b4eb132/src/unix/bsd/freebsdlike/freebsd/= freebsd11/mod.rs#L8
> https://github.com/rust-lang/libc/blob= /72c40004a3568849055c0bab5c92c9975b4eb132/src/unix/bsd/freebsdlike/freebsd/= freebsd12/mod.rs#L5
>
> Seems to have changed to 64 bit for FreeBSD 12 and up?

Rust libc seems to make some strange things to follow FreeBSD ABI
evolution, which is not done e.g. for glibc.=C2=A0 But anyway, the relevant= place
to look seems to be a comment and decision code at
https://= github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b4eb132/bui= ld.rs#L44

By default they seems to use FreeBSD 11 ABI from freebsd11 module still. I do not know what is CARGO_FEATURE_RUSTC_DEP_OF_STD.

CARGO_FEATURE_RUSTC_DEP_OF_STD is an environment vari= able set by cargo when libc is built with the rustc-dep-of-std=C2=A0feature= , as is done when building the std library. What this means is that the std= library uses a libc ABI that is backwards compatible with FreeBSD 12. When= using a standalone libc from crates.io yo= u will get libc bindings that are backwards compatible with FreeBSD 11. Def= initely not entirely clear to me. I made a small sample app that prints the= size of libc::ino_t. Building this app without any environment variables d= efined results in a size of 4. Building with `LIBC_CI=3D1` results in a siz= e of 8, as does building with `CARGO_FEATURE_RUSTC_DEP_OF_STD=3D1`. These t= ests were done on a host running FreeBSD 15.
--000000000000243d8b062154f445--