From nobody Fri Jan 19 18:49:31 2024 X-Original-To: dev-commits-src-all@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 4TGpZ44Wj2z577ry; Fri, 19 Jan 2024 18:49:32 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 4TGpZ42qHDz4jk4; Fri, 19 Jan 2024 18:49:32 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Authentication-Results: mx1.freebsd.org; none Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 3FC203C019A; Fri, 19 Jan 2024 18:49:31 +0000 (UTC) Date: Fri, 19 Jan 2024 18:49:31 +0000 From: Brooks Davis To: John Baldwin Cc: Alan Somers , Enji Cooper , "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: References: <202401172250.40HMo4O9003460@gitrepo.freebsd.org> <8F36170D-9592-46D5-A275-12E24C3A13D8@gmail.com> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4TGpZ42qHDz4jk4 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:36236, ipnet:199.48.128.0/22, country:US] On Fri, Jan 19, 2024 at 10:15:06AM -0800, John Baldwin wrote: > On 1/19/24 7:38 AM, Alan Somers wrote: > > On Fri, Jan 19, 2024 at 6:56???AM Alan Somers wrote: > > > > > > On Thu, Jan 18, 2024 at 10:32???PM Enji Cooper wrote: > > > > > > > > > > > > > On Jan 17, 2024, at 2:50???PM, Alan Somers wrote: > > > > > > > > > > The branch main has been updated by asomers: > > > > > > > > > > URL: https://cgit.FreeBSD.org/src/commit/?id=8bae22bbbe6571da9259e0d43ffa8a56f4b3e171 > > > > > > > > > > commit 8bae22bbbe6571da9259e0d43ffa8a56f4b3e171 > > > > > Author: Alan Somers > > > > > AuthorDate: 2024-01-15 23:49:47 +0000 > > > > > Commit: Alan Somers > > > > > CommitDate: 2024-01-17 22:49:41 +0000 > > > > > > > > > > fusefs: prefer new/delete over malloc/free > > > > > > > > > > MFC after: 2 weeks > > > > > Reviewed by: kib > > > > > Differential Revision: https://reviews.freebsd.org/D43464 > > > > > > > > Why not use smart pointers instead? > > > > -Enji > > > > > > 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 contrib. > > Brooks' opinion is that to support Rust in base we probably need to require > always using an external toolchain as otherwise we would need to keep two > copies of LLVM in base. I think the most sensible route is to start bringing in Rust code that requires an external toolchain. The first step would probably be to figure out how to build a helloworld with a RUST_TOOLCHAIN variable set and no network access. There are a bunch of bootstrapping and reproducibility issues to consider, but I think the fixes mostly lie outside the src tree. -- Brooks