Date: Fri, 19 Jan 2024 10:24:25 -0800 From: Enji Cooper <yaneurabeya@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: Alan Somers <asomers@freebsd.org>, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 8bae22bbbe65 - main - fusefs: prefer new/delete over malloc/free Message-ID: <2A5657AE-C55D-492A-9013-9CFE1F80ED9C@gmail.com> In-Reply-To: <bb78e4d5-3ae5-47ed-8c92-cebb04e6585a@FreeBSD.org> References: <bb78e4d5-3ae5-47ed-8c92-cebb04e6585a@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jan 19, 2024, at 10:15, John Baldwin <jhb@freebsd.org> wrote: >=20 > =EF=BB=BFOn 1/19/24 7:38 AM, Alan Somers wrote: >>> On Fri, Jan 19, 2024 at 6:56=E2=80=AFAM Alan Somers <asomers@freebsd.org= > wrote: >>>=20 >>> On Thu, Jan 18, 2024 at 10:32=E2=80=AFPM Enji Cooper <yaneurabeya@gmail.= com> wrote: >>>>=20 >>>>=20 >>>>> On Jan 17, 2024, at 2:50=E2=80=AFPM, Alan Somers <asomers@FreeBSD.org>= wrote: >>>>>=20 >>>>> The branch main has been updated by asomers: >>>>>=20 >>>>> URL: https://cgit.FreeBSD.org/src/commit/?id=3D8bae22bbbe6571da9259e0d= 43ffa8a56f4b3e171 >>>>>=20 >>>>> commit 8bae22bbbe6571da9259e0d43ffa8a56f4b3e171 >>>>> Author: Alan Somers <asomers@FreeBSD.org> >>>>> AuthorDate: 2024-01-15 23:49:47 +0000 >>>>> Commit: Alan Somers <asomers@FreeBSD.org> >>>>> CommitDate: 2024-01-17 22:49:41 +0000 >>>>>=20 >>>>> fusefs: prefer new/delete over malloc/free >>>>>=20 >>>>> MFC after: 2 weeks >>>>> Reviewed by: kib >>>>> Differential Revision: https://reviews.freebsd.org/D43464 >>>>=20 >>>> Why not use smart pointers instead? >>>> -Enji >>>=20 >>> Only because this stuff all evolved from C code. Smart pointers would >>> certainly work. >> Actually, TBH it's because I'm not real great with C++. It's a >> difficult language, and after 2016 I stopped even trying to improve my >> C++ skills. Instead, I've been focusing on Rust. Even when I wrote >> these tests in 2019, I strongly considered using Rust instead of C++. >> In the end, the only thing that forced me to use C++ is because I >> wanted them to live in the base system, rather than in ports. >> I still dream about the day when Rust is allowed in the base system. >> If it were, then in addition to these tests, I would've converted >> gstat to Rust (rather than add sysutils/gstat-rs to ports), added the >> nfs-exporter (instead of putting it in net-mgmt/nfs-exporter), added a >> ctl-exporter (which is impossible to do in ports, so I had to do that >> one in C), and converted tools/regression/fsx in place (instead of >> putting in devel/fsx-rs). Maybe a couple of other things, too. Like >> ztop, or the geom-exporter that I have half-written. I've also been >> tempted to rewrite zfsd in Rust. >> Alas, I sense that there is little appetite for bringing Rust into contri= b. >=20 > Brooks' opinion is that to support Rust in base we probably need to requir= e > always using an external toolchain as otherwise we would need to keep two > copies of LLVM in base. Based on my recent adventures with this, I concur. Our version of LLVM in ba= se is not compatible with the copy rust needs, so rust would always need to b= e bootstrapped with world. It would need to be a full toolchain as well to build all of the rust target= s. Using llvm built for a single target would only function as the initial b= ootstrap toolchain. Finally, the bootstrap compiler (via rustup) has tight requirements around v= ersioning and is precompiled for the host. It turns into a nightmare if new s= yscall support is added or if compat support is required to run the binary=E2= =80=A6 We=E2=80=99d be better off importing golang instead of rust. HTH, -Enji=20=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2A5657AE-C55D-492A-9013-9CFE1F80ED9C>