Date: Fri, 19 Jan 2024 11:36:08 -0700 From: Warner Losh <imp@bsdimp.com> To: Enji Cooper <yaneurabeya@gmail.com> Cc: John Baldwin <jhb@freebsd.org>, 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: <CANCZdfpjeDj7fSxmKY5cB5mvaUwtVFvy%2BzySouzQSL=7BY5KrA@mail.gmail.com> In-Reply-To: <2A5657AE-C55D-492A-9013-9CFE1F80ED9C@gmail.com> References: <bb78e4d5-3ae5-47ed-8c92-cebb04e6585a@FreeBSD.org> <2A5657AE-C55D-492A-9013-9CFE1F80ED9C@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000937bef060f50c177 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 19, 2024 at 11:24=E2=80=AFAM Enji Cooper <yaneurabeya@gmail.com= > wrote: > > > On Jan 19, 2024, at 10:15, John Baldwin <jhb@freebsd.org> wrote: > > > > =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: > >>> > >>> On Thu, Jan 18, 2024 at 10:32=E2=80=AFPM Enji Cooper <yaneurabeya@gma= il.com> > wrote: > >>>> > >>>> > >>>>> On Jan 17, 2024, at 2:50=E2=80=AFPM, Alan Somers <asomers@FreeBSD.o= rg> > wrote: > >>>>> > >>>>> The branch main has been updated by asomers: > >>>>> > >>>>> URL: > https://cgit.FreeBSD.org/src/commit/?id=3D8bae22bbbe6571da9259e0d43ffa8a5= 6f4b3e171 > >>>>> > >>>>> 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 > >>>>> > >>>>> 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 woul= d > >>> 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 t= wo > > copies of LLVM in base. > > Based on my recent adventures with this, I concur. Our version of LLVM in > base is not compatible with the copy rust needs, so rust would always nee= d > to be bootstrapped with world. > > It would need to be a full toolchain as well to build all of the rust > targets. Using llvm built for a single target would only function as the > initial bootstrap toolchain. > > Finally, the bootstrap compiler (via rustup) has tight requirements aroun= d > versioning and is precompiled for the host. It turns into a nightmare if > new syscall 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. > I have no problems supporting rust via an external toolchain, but I'd also view that support to be provisional: Show us what can be done better and the niggling issues that one hits around toolchain stuff somehow is paid for with something that's way cooler than we could otherwise have. Tests seem like a natural first step in that. I mean, if we can't even support tests without it being a hassle, then it's a complete no-go. If we can, then what else can we support? For more ambitious things, there's always ports and the base / ports distinction is likely to fade somewhat as pkgbase becomes more mature. Warner --000000000000937bef060f50c177 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jan 19, 2024 at 11:24=E2=80= =AFAM Enji Cooper <<a href=3D"mailto:yaneurabeya@gmail.com">yaneurabeya@= gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex"><br> > On Jan 19, 2024, at 10:15, John Baldwin <<a href=3D"mailto:jhb@free= bsd.org" target=3D"_blank">jhb@freebsd.org</a>> wrote:<br> > <br> > =EF=BB=BFOn 1/19/24 7:38 AM, Alan Somers wrote:<br> >>> On Fri, Jan 19, 2024 at 6:56=E2=80=AFAM Alan Somers <<a hre= f=3D"mailto:asomers@freebsd.org" target=3D"_blank">asomers@freebsd.org</a>&= gt; wrote:<br> >>> <br> >>> On Thu, Jan 18, 2024 at 10:32=E2=80=AFPM Enji Cooper <<a hr= ef=3D"mailto:yaneurabeya@gmail.com" target=3D"_blank">yaneurabeya@gmail.com= </a>> wrote:<br> >>>> <br> >>>> <br> >>>>> On Jan 17, 2024, at 2:50=E2=80=AFPM, Alan Somers <a= somers@FreeBSD.org> wrote:<br> >>>>> <br> >>>>> The branch main has been updated by asomers:<br> >>>>> <br> >>>>> URL: <a href=3D"https://cgit.FreeBSD.org/src/commit/?i= d=3D8bae22bbbe6571da9259e0d43ffa8a56f4b3e171" rel=3D"noreferrer" target=3D"= _blank">https://cgit.FreeBSD.org/src/commit/?id=3D8bae22bbbe6571da9259e0d43= ffa8a56f4b3e171</a><br> >>>>> <br> >>>>> commit 8bae22bbbe6571da9259e0d43ffa8a56f4b3e171<br> >>>>> Author:=C2=A0 =C2=A0 =C2=A0Alan Somers <asomers@Fre= eBSD.org><br> >>>>> AuthorDate: 2024-01-15 23:49:47 +0000<br> >>>>> Commit:=C2=A0 =C2=A0 =C2=A0Alan Somers <asomers@Fre= eBSD.org><br> >>>>> CommitDate: 2024-01-17 22:49:41 +0000<br> >>>>> <br> >>>>>=C2=A0 =C2=A0 fusefs: prefer new/delete over malloc/fre= e<br> >>>>> <br> >>>>>=C2=A0 =C2=A0 MFC after:=C2=A0 =C2=A0 =C2=A0 2 weeks<br= > >>>>>=C2=A0 =C2=A0 Reviewed by:=C2=A0 =C2=A0 kib<br> >>>>>=C2=A0 =C2=A0 Differential Revision: <a href=3D"https:/= /reviews.freebsd.org/D43464" rel=3D"noreferrer" target=3D"_blank">https://r= eviews.freebsd.org/D43464</a><br> >>>> <br> >>>> Why not use smart pointers instead?<br> >>>> -Enji<br> >>> <br> >>> Only because this stuff all evolved from C code.=C2=A0 Smart p= ointers would<br> >>> certainly work.<br> >> Actually, TBH it's because I'm not real great with C++.=C2= =A0 It's a<br> >> difficult language, and after 2016 I stopped even trying to improv= e my<br> >> C++ skills.=C2=A0 Instead, I've been focusing on Rust.=C2=A0 E= ven when I wrote<br> >> these tests in 2019, I strongly considered using Rust instead of C= ++.<br> >> In the end, the only thing that forced me to use C++ is because I<= br> >> wanted them to live in the base system, rather than in ports.<br> >> I still dream about the day when Rust is allowed in the base syste= m.<br> >> If it were, then in addition to these tests, I would've conver= ted<br> >> gstat to Rust (rather than add sysutils/gstat-rs to ports), added = the<br> >> nfs-exporter (instead of putting it in net-mgmt/nfs-exporter), add= ed a<br> >> ctl-exporter (which is impossible to do in ports, so I had to do t= hat<br> >> one in C), and converted tools/regression/fsx in place (instead of= <br> >> putting in devel/fsx-rs).=C2=A0 Maybe a couple of other things, to= o.=C2=A0 Like<br> >> ztop, or the geom-exporter that I have half-written.=C2=A0 I'v= e also been<br> >> tempted to rewrite zfsd in Rust.<br> >> Alas, I sense that there is little appetite for bringing Rust into= contrib.<br> > <br> > Brooks' opinion is that to support Rust in base we probably need t= o require<br> > always using an external toolchain as otherwise we would need to keep = two<br> > copies of LLVM in base.<br> <br> Based on my recent adventures with this, I concur. Our version of LLVM in b= ase is not compatible with the copy rust needs, so rust would always need t= o be bootstrapped with world.<br> <br> It would need to be a full toolchain as well to build all of the rust targe= ts. Using llvm built for a single target would only function as the initial= bootstrap toolchain.<br> <br> Finally, the bootstrap compiler (via rustup) has tight requirements around = versioning and is precompiled for the host. It turns into a nightmare if ne= w syscall support is added or if compat support is required to run the bina= ry=E2=80=A6<br> <br> We=E2=80=99d be better off importing golang instead of rust.<br></blockquot= e><div><br></div><div>I have no problems supporting rust via an external to= olchain, but I'd also view that support</div><div>to be provisional: Sh= ow us what can be done better and the niggling issues that one hits</div><d= iv>around toolchain stuff somehow is paid for with something that's way= cooler than we could</div><div>otherwise have. Tests seem like a natural f= irst step in that. I mean, if we can't even support</div><div>tests wit= hout it being a hassle, then it's a complete no-go. If we can, then wha= t else can we</div><div>support? For more ambitious things, there's alw= ays ports and the base / ports distinction is</div><div>likely to fade some= what as pkgbase becomes more mature.</div><div><br></div><div>Warner</div><= /div></div> --000000000000937bef060f50c177--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpjeDj7fSxmKY5cB5mvaUwtVFvy%2BzySouzQSL=7BY5KrA>