Date: Wed, 4 Sep 2024 18:10:06 -0700 From: Jacques Fourie <jacques.fourie@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Cy Schubert <Cy.Schubert@cschubert.com>, Jan Knepper <jan@digitaldaemon.com>, Mark Delany <x9k@charlie.emu.st>, freebsd-hackers@freebsd.org Subject: Re: Rust: kernel vs user-space Message-ID: <CALX0vxBerLn4Mmu8D6DyAHyvg3iFMrVRjt-K1jCjF5RVVELAGQ@mail.gmail.com> In-Reply-To: <Ztj3ITmqq68bRBbI@kib.kiev.ua> References: <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com> <20240904221522.63E0366@slippy.cwsent.com> <Ztjh773c6Rwo6BTQ@kib.kiev.ua> <CALX0vxCq0hVocahyoe_wk7NG2nF55T2ue7enUR33sPZHtKnqUw@mail.gmail.com> <Ztj3ITmqq68bRBbI@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Wed, Sep 4, 2024 at 5:13 PM Konstantin Belousov <kostikbel@gmail.com> wrote: > On Wed, Sep 04, 2024 at 04:43:31PM -0700, Jacques Fourie wrote: > > On Wed, Sep 4, 2024 at 3:41 PM Konstantin Belousov <kostikbel@gmail.com> > > 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 representation > 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/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. But anyway, the relevant > place > to look seems to be a comment and decision code at > > https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b4eb132/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=1` results in a size of 8, as does building with `CARGO_FEATURE_RUSTC_DEP_OF_STD=1`. These tests were done on a host running FreeBSD 15. [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 4, 2024 at 5:13 PM Konstantin Belousov <<a href="mailto:kostikbel@gmail.com">kostikbel@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Wed, Sep 04, 2024 at 04:43:31PM -0700, Jacques Fourie wrote:<br> > On Wed, Sep 4, 2024 at 3:41 PM Konstantin Belousov <<a href="mailto:kostikbel@gmail.com" target="_blank">kostikbel@gmail.com</a>><br> > wrote:<br> > <br> > > On Wed, Sep 04, 2024 at 03:15:22PM -0700, Cy Schubert wrote:<br> > > > In message <<a href="mailto:78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com" target="_blank">78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com</a>>,<br> > > Jan<br> > > > Kneppe<br> > > > r writes:<br> > > > > D<br> > > > ><br> > > > > <a href="http://www.dlang.org" rel="noreferrer" target="_blank">www.dlang.org</a><br> > > ><br> > > > The problem with D is data structure definitions need to also be<br> > > mirrored<br> > > > (duplicated) in D. For example, when 64-bit inodes were implemented D<br> > > > failed to build and generate any code. The reason for this was<br> > > > ufs/ufs/inode.h now defined 64-bit inodes while the D representation as<br> > > > provided by the D language were still 32-bit. I had opened an issue with<br> > > > upstream regarding this. To this day they still haven't figured out how<br> > > to<br> > > > implement 64-bit inodes on newer FreeBSD systems while maintaining<br> > > 32-bit<br> > > > inode backward compatibility on older FreeBSD systems (as FreeBSD<br> > > > implemented this using ifunc).<br> > ><br> > > Rust is same. It still uses pre-ino64 bindings for both stdlib and libc.<br> > ><br> > <br> > Looking at the Rust libc bindings I see the following:<br> > <a href="https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b4eb132/src/unix/bsd/freebsdlike/freebsd/freebsd11/mod.rs#L8" rel="noreferrer" target="_blank">https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b4eb132/src/unix/bsd/freebsdlike/freebsd/freebsd11/mod.rs#L8</a><br>; > <a href="https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b4eb132/src/unix/bsd/freebsdlike/freebsd/freebsd12/mod.rs#L5" rel="noreferrer" target="_blank">https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b4eb132/src/unix/bsd/freebsdlike/freebsd/freebsd12/mod.rs#L5</a><br>; > <br> > Seems to have changed to 64 bit for FreeBSD 12 and up?<br> <br> Rust libc seems to make some strange things to follow FreeBSD ABI<br> evolution, which is not done e.g. for glibc. But anyway, the relevant place<br> to look seems to be a comment and decision code at<br> <a href="https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b4eb132/build.rs#L44" rel="noreferrer" target="_blank">https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b4eb132/build.rs#L44</a><br>; <br> By default they seems to use FreeBSD 11 ABI from freebsd11 module still.<br> I do not know what is CARGO_FEATURE_RUSTC_DEP_OF_STD.<br> <br></blockquote><div>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 <a href="http://crates.io">crates.io</a>; 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=1` results in a size of 8, as does building with `CARGO_FEATURE_RUSTC_DEP_OF_STD=1`. These tests were done on a host running FreeBSD 15.</div></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALX0vxBerLn4Mmu8D6DyAHyvg3iFMrVRjt-K1jCjF5RVVELAGQ>