From nobody Fri Jan 19 18:19:47 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 4TGnw021zQz574yC for ; Fri, 19 Jan 2024 18:20:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TGnvz6bMyz4Zkt for ; Fri, 19 Jan 2024 18:19:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-55a45a453eeso1308651a12.0 for ; Fri, 19 Jan 2024 10:19:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1705688398; x=1706293198; 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=xZh5mpH9wxIPQR3uCCooct92F8NqAH7a6N+nmjbwaXQ=; b=Uck27CiyJljjHgClcjjYI4+4b3GX+DZRHWiyE88cS2tsPuyeo2O5UZXLWDWnqNp1YH OzAV5zM83tPJZoTnMLVdo5DEYVV7QcMdmvQjyk3mWToF78HhufF7mnMmLrayzxpbBmv4 im8x7JY4AptMoqt0FDKvOyFkRX/GJwsmMsgIZ7lQ2mSp8uGJT0CA4NJFRZqMIB+aQOil Dy0mhZ72t2T9g8ZJERLqnhi4Z3U5QknO21Odk4TCGEr72qBRtuZRHVb2ETMv0VrwbVuc pSAuU4P/CZblGkeHUO88nDgEV+NQS08OMdSSTgaEXXUR9T6ZhHSzP5fSnbIV8Mj+8Vpx trOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705688398; x=1706293198; 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=xZh5mpH9wxIPQR3uCCooct92F8NqAH7a6N+nmjbwaXQ=; b=O3PeAb4uba4kpc71vhNmH90UU+sQR5HtxXmx1Oi9/zhVHYePj5Rfz8STpvLruNDZB+ L0BjTF+SckRSjDuJvasy4Zud1mdlnk+SsVcWv7e0NP0wbliNlMaO1gae+6fiEq7GOIH9 m3ebdxZ/bJ97HQqD4EQCu43s953HmwiPdJF3kmV5bBNG3DrIMYNFNP0nmP0zGejUM/xP 7UHHLK0R8a5WH4fyX3sgVLKcPToBGwxqL+oKeHtIcw1mHoWkQJ4XVwVTMN1KPaEbnoT5 TIJGh5yea7ZzUxUJ47fnY+EkkKiPsjSR/7sMy/rrVCaVhq+N8bVStyIecE7J6XKiF1Jy Pllw== X-Gm-Message-State: AOJu0YyDEP8V2sJslbTPQAKDS1rKDcnYJm/3cwjuScfOTSs5QJi91lUi jLqJlyXANNWJryNjP5wBVVB5NGim60LRQ+gOBIOPRp65WaiP7KynCjrBXwEiTcaCIP0q048M61v SW0aM0zeCFP39RruapQeLXsNg+1aLfnJG5r8YVg== X-Google-Smtp-Source: AGHT+IH9wa6hpbdKB+ip5gjH9TLucb6C+bjjNnCOW6j6Jr7L6NtZggihHkC1qTCkDed0QWCHSu8SDF6mRlGs7y+lkh4= X-Received: by 2002:a05:6402:b21:b0:558:2ed7:3bfd with SMTP id bo1-20020a0564020b2100b005582ed73bfdmr79703edb.68.1705688398410; Fri, 19 Jan 2024 10:19:58 -0800 (PST) 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 References: <202401172250.40HMo4O9003460@gitrepo.freebsd.org> <8F36170D-9592-46D5-A275-12E24C3A13D8@gmail.com> In-Reply-To: From: Warner Losh Date: Fri, 19 Jan 2024 11:19:47 -0700 Message-ID: Subject: Re: git: 8bae22bbbe65 - main - fusefs: prefer new/delete over malloc/free To: Alan Somers Cc: Enji Cooper , src-committers , "" , "" Content-Type: multipart/alternative; boundary="00000000000015c6b8060f50870e" X-Rspamd-Queue-Id: 4TGnvz6bMyz4Zkt 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:15169, ipnet:2a00:1450::/32, country:US] --00000000000015c6b8060f50870e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 19, 2024, 8:39=E2=80=AFAM Alan Somers wro= te: > On Fri, Jan 19, 2024 at 6:56=E2=80=AFAM Alan Somers = wrote: > > > > On Thu, Jan 18, 2024 at 10:32=E2=80=AFPM Enji Cooper > wrote: > > > > > > > > > > On Jan 17, 2024, at 2:50=E2=80=AFPM, Alan Somers > wrote: > > > > > > > > The branch main has been updated by asomers: > > > > > > > > URL: > https://cgit.FreeBSD.org/src/commit/?id=3D8bae22bbbe6571da9259e0d43ffa8a5= 6f4b3e171 > > > > > > > > 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 contri= b. > I'd love there to be more tests written. One of the problems (one of many) with the tests is they are build during buildworld. This constrains them a bit too much, imho. While we can add a bunch of tests that are written in interpreted languages like python, per= l or pdksh, it's harder to add one written in an alternative language that's then compiled. Sometimes I think we should have a separate buildtests installtests which assume a post-installworld environment. That would let us build go, rust, etc tests. Though managing the crates, etc for the build might prove to be an interesting, though ports manage fairly well with carefully constructed packages. Rust is still evolving quickly relative to C. While C++ is also, it's not widely used in the tree so that evolution doesn't matter so much (though devd likely needs a full re-write) For rust to be considered in base, the community of developers likely would need to see visible success stories. While the ports that do the testing you mentioned are a good start, I'm of the opinion that having in-tree rust test cases would be helpful. Though there's no rust integration for kyua / ATF right now. I'd love to find some way to make this happen, possibly with the requirement that pkg install rust be done prior to the build, to show it's possible and to raise awareness of rust's viability and to shake out the inevitable growing pains that this will necessarily case. Tests are a good place to start since we already have a high burden on the users of the tests in terms of packages installed. We could have an opt-in set of rust tests that would fail if you didn't have the right ports installed (which we could encode into a metaport to keep it easy). But rust, itself, in the base has a lot of logistical issues since it isn't quite supported in llvm out of the box (I see john's note just now touching on this as well). But to put up with the logistical issues, there needs to be clearly demonstrated wins in our environment first, imho. I really, though, would be concerned if this means we go from 2 llvm builds to 4. Warner > --00000000000015c6b8060f50870e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jan 19, 2024, 8:39=E2=80=AFAM= Alan Somers <a= somers@freebsd.org> wrote:
O= n Fri, Jan 19, 2024 at 6:56=E2=80=AFAM Alan Somers <asomers@freebsd.org= > wrote:
>
> On Thu, Jan 18, 2024 at 10:32=E2=80=AFPM Enji Cooper <yaneurabey= a@gmail.com> wrote:
> >
> >
> > > On Jan 17, 2024, at 2:50=E2=80=AFPM, Alan Somers <asomers= @FreeBSD.org> wrote:
> > >
> > > The branch main has been updated by asomers:
> > >
> > > URL: https://cgit.FreeBSD.org/src/commit/?id=3D8bae22bbbe6571da9259= e0d43ffa8a56f4b3e171
> > >
> > > commit 8bae22bbbe6571da9259e0d43ffa8a56f4b3e171
> > > Author:=C2=A0 =C2=A0 =C2=A0Alan Somers <asomers@FreeBSD.o= rg>
> > > AuthorDate: 2024-01-15 23:49:47 +0000
> > > Commit:=C2=A0 =C2=A0 =C2=A0Alan Somers <asomers@FreeBSD.o= rg>
> > > CommitDate: 2024-01-17 22:49:41 +0000
> > >
> > >=C2=A0 =C2=A0 fusefs: prefer new/delete over malloc/free
> > >
> > >=C2=A0 =C2=A0 MFC after:=C2=A0 =C2=A0 =C2=A0 2 weeks
> > >=C2=A0 =C2=A0 Reviewed by:=C2=A0 =C2=A0 kib
> > >=C2=A0 =C2=A0 Differential Revision: http= s://reviews.freebsd.org/D43464
> >
> > Why not use smart pointers instead?
> > -Enji
>
> Only because this stuff all evolved from C code.=C2=A0 Smart pointers = would
> certainly work.

Actually, TBH it's because I'm not real great with C++.=C2=A0 It= 9;s a
difficult language, and after 2016 I stopped even trying to improve my
C++ skills.=C2=A0 Instead, I've been focusing on Rust.=C2=A0 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).=C2=A0 Maybe a couple of other things, too.=C2=A0 = Like
ztop, or the geom-exporter that I have half-written.=C2=A0 I've also be= en
tempted to rewrite zfsd in Rust.

Alas, I sense that there is little appetite for bringing Rust into contrib.=

I'd love = there to be more tests written.

One of the problem= s (one of many) with the tests is they are build during
buildworl= d. This constrains them a bit too much, imho. While we can add
a = bunch of tests that are written in interpreted languages like python, perl<= /div>
or pdksh, it's harder to add one written in an alternative la= nguage that's
then compiled. Sometimes I think we should have= a separate buildtests
installtests=C2=A0which assume a post-inst= allworld environment. That would let
us build go, rust, etc tests= . Though managing the crates, etc for the build
might prove to be= an interesting, though ports manage fairly well with carefully
c= onstructed packages.

Rust is still evolving quickl= y relative to C. While C++ is also, it's not widely
used in t= he tree so that evolution doesn't matter so much (though devd
likely needs a full re-write)

For rust to be cons= idered=C2=A0in base, the community=C2=A0of developers=C2=A0likely
would need to see visible success stories. While the ports that do
the testing you mentioned are a good start, I'm of the opinion that<= /div>
having in-tree rust test cases would be helpful. Though there'= ;s no
rust integration for kyua / ATF right now. I'd love to = find some way to
make this happen, possibly with the requirement = that pkg install rust
be done prior to the build, to show it'= s possible and to raise awareness
of rust's viability and to = shake out the inevitable growing pains that
this will necessarily= case. Tests are a good place to start since
we already have a hi= gh burden on the users of the tests in terms of
packages installe= d. We could have an opt-in set of rust tests that
would fail if y= ou didn't have the right ports installed (which we could
enco= de into a metaport to keep it easy).

But rust, its= elf, in the base has a lot of logistical issues since it isn't
quite supported in llvm out of the box (I see john's note just now to= uching
on this as well). But to put up with the logistical issues= , there needs to
be clearly demonstrated wins in our environment = first, imho. I really,
though, would be concerned if this means w= e go from 2 llvm builds to 4.

Warner
--00000000000015c6b8060f50870e--