Date: Sat, 20 Jan 2024 20:30:55 -0700 From: Warner Losh <imp@bsdimp.com> To: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> Cc: Aleksandr Fedorov <wigneddoom@yandex.ru>, Alan Somers <asomers@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, Scott Long <scottl@freebsd.org>, "Goran Meki??" <meka@tilda.center> Subject: Re: The Case for Rust (in the base system) Message-ID: <CANCZdfprPW2NOZaRCQJqFao3oKaJVE-ToHB-wVyBegLYkR3HRw@mail.gmail.com> In-Reply-To: <20240121110611.af567b0ac3a8fd8593ffcb7f@dec.sakura.ne.jp> References: <CAOtMX2hAUiWdGPtpaCJLPZB%2Bj2yzNw5DSjUmkwTi%2B%2BmyemehCA@mail.gmail.com> <1673801705774097@mail.yandex.ru> <CANCZdfpqWgvV_RCvVO_pvTrmajQFspW%2BQ9TM_Ok3JrXZAfeAfA@mail.gmail.com> <20240121110611.af567b0ac3a8fd8593ffcb7f@dec.sakura.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000fa7706060f6c5723 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jan 20, 2024, 7:06=E2=80=AFPM Tomoaki AOKI <junchoon@dec.sakura.ne.= jp> wrote: > On Sat, 20 Jan 2024 15:31:23 -0700 > Warner Losh <imp@bsdimp.com> wrote: > > > On Sat, Jan 20, 2024 at 11:45=E2=80=AFAM Aleksandr Fedorov <wigneddoom@= yandex.ru > > > > wrote: > > > > > What about external dependencies? > > > > > > > https://github.com/Axcient/freebsd-nfs-exporter/blob/master/Cargo.toml#L1= 9 > > > https://github.com/asomers/gstat-rs/blob/master/gstat/src/main.rs#L20 > > > > > > Is there any plan for which crates we should take into the base syste= m? > > > > > > We have had C++ in base for many years, but I don=E2=80=99t see any g= ood > libraries > > > for CLI, logging, JSON, etc. > > > > > > > > > > https://doc.rust-lang.org/rustc/platform-support.html#tier-1-with-host-to= ols > > > > > > Where is the support for Freebsd as a primary platform? ARM, RISC-V, > > > Power? Should we rewrite devd? > > > > > > I think we need to start by providing official repositories (e.g > > > git.FreeBSD.org/rust.git or git.FreeBSD.org/go.git) > > > for different languages that include stable bindings to the system AP= I: > > > - sysctl > > > - libgeom > > > - libifconfig > > > - netgraph > > > - jail > > > - etc. > > > > > > So that it=E2=80=99s not just some anonymous on crates.io that repres= ents > these > > > bindings, but our community. > > > Officially, with support for a stable ABI for releases, security > patches, > > > etc. > > > > > > After this, it will be possible to think about which components to > include > > > in the base system. > > > > > > I would be glad to see a more modern language than C in the database, > but > > > I=E2=80=99m afraid that it will be like with C++, > > > that we will get a couple of daemons and utilities and that=E2=80=99s= all. > > > > > > > These are all good questions that need good answers, though necessarily > to > > get started. > > > > But the other question that occured to me after my last posting was "Wh= at > > about build integration?" > > How much of the rust automation do we take in vs how much do we drive > from > > a future bsd.rust.mk. > > I can sketch out bsd.rust.mk (to pick an arbitrary name, we'd likely > need > > one for what we traditionally > > think of as libraries (which may or may not map 1:1 onto crates: we cou= ld > > have c callable libraries > > written in rust in the future, for example) and one for binaries. > > Initially, though, if we go with the > > 'make rust tests possible' then we'd likely need the appropriate packag= es > > installed for whatever > > dependencies we'd have in the tests. This would give us a taste for wha= t > > we'd need to do for > > base, I'd think. Once we had that notion, I can easily see there needin= g > to > > be some sort of > > rust bindings for ATF/kyua as one of the first libraries / crates that > > would test that aspect of > > the build system. That all would be up to the people writing the tests = in > > rust, I'd imagine. > > > > While I could jot out the basics of this integration (so one could just > add > > the rust > > tools to a subdir or subdirs, include the bsd.rust.mk or whatever and > then > > it would build > > if rust is enabled, and would emit a warning it was skipped because rus= t > > was disabled). > > We'd find out if this is workable or not and iterate from there. But th= at > > would also require > > active participation from the rust advocates to make it a reality: I ca= n > > put together the > > build infrastructure for the disabled case, but likely can't on my own = do > > the rust enabled > > case. I'd be happy to work with someone to do that, but I'm not going t= o > be > > able to do > > that myself: my need for rust is slight, my knowledge of rust is weak, > etc. > > Working with > > someone (or ideally several someones), though it could become reality. = So > > please contact > > me if you'd like to work on this. > > > > Warner > > One way to go could be moving programs rewritten with rust to ports. > There are some programs (not in rust, though) moved to ports, like rcs. > Yes. And a number of programs have been made available as ports, but not too many replace c programs. Currently, it would not be so realistic, but once we completely switch > to pkgbase, IIUC, programs in base can sanely depemd on ports programs, > excluding kernel and fundamental libraries. Possible, but I'd wager not for quite some time for fundamental things. I could be wrong on this timeline... As non-rust consumers of graphics/librsvg2-rust can sanely link with > it, I assume kmods in ports written in rust can kldload'ed sanely. > This could be a good starting point. > Kernel modules are far off om the horizon at this point. There was a proof of concept done years ago, but much has changed so an effort is needed to get back to that basic point. And would be not all, but test for rust libraries could be implemented > with C/C++ or any other language suitable, if the rust libraries can > sanely linked with test codes. > That's not a given... ABIs are hard enough without a C to rust layer sneaking in. Warner Am I wrong? > > > > > 20.01.2024, 19:51, "Alan Somers" <asomers@freebsd.org>: > > > > > > In a recent thread on src-committers, we discussed the costs and > > > benefits of including Rust code in the FreeBSD base system. To > > > summarize, the cost is that it would double our build times. imp > > > suggested adding an additional step after buildworld for stuff that > > > requires an external toolchain. That would ease the build time pain. > > > The benefit is that some tools would become easier to write, or even > > > become possible. Here is a list of actual and potential Rust projects > > > that could benefit from being in-tree. If anybody else has items to > > > add, I suggest moving this into the project wiki: > > > > > > Stuff that could only be written in Rust if it were in base > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > * ctl-exporter (I started this, but discovered that the CTL stats API > is > > > unstable, so it can't live in ports. Instead, I had to do it in C). > > > > > > > https://github.com/freebsd/freebsd-src/commit/1a7f22d9c211f504f6c48a86401= 469181a67ec34 > > > > > > * fusefs tests. Absolutely impossible to do in C. I considered Rust, > but > > > went > > > with C++ so they could live in base. They are too closely coupled t= o > > > fusefs(5) to live out-of-tree. > > > https://github.com/freebsd/freebsd-src/tree/main/tests/sys/fs/fusef= s > > > > > > * devd. Currently C++, but imp suggested a rewrite. > > > https://github.com/freebsd/freebsd-src/tree/main/sbin/devd > > > > > > * zfsd. Currently C++, but I've long pondered a rewrite. Using Rust > would > > > make it more testable. > > > https://github.com/freebsd/freebsd-src/tree/main/cddl/usr.sbin/zfsd > > > > > > * nscd. Currently C, but confusing and with no test coverage. I've > > > contemplated a rewrite myself, but I don't want to do it in C. > > > https://github.com/freebsd/freebsd-src/tree/main/usr.sbin/nscd > > > > > > * The userland portion of the 802.11ac and Lightning stacks. scottl > > > suggested > > > that these were good candidates for Rust. > > > > > > * freebsd-kpi-r14-0 . https://crates.io/crates/freebsd-kpi-r14-0 > > > > > > Stuff that can live in ports, but would be nicer in base > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > * gstat-rs https://crates.io/crates/gstat > > > > > > * geom-exporter (I've started this, but haven't published it) > > > > > > * nfs-exporter https://crates.io/crates/freebsd-nfs-exporter > > > > > > * virtiofsd-rs . Nobody has yet tried to port it to FreeBSD. But if t= he > > > connection to bhyve(8) is too intimate, it might be hard to do in > ports. > > > https://gitlab.com/virtio-fs/virtiofsd > > > > > > * jail-exporter https://crates.io/crates/jail_exporter > > > > > > * Various jail managers have been attempted in Rust. I think these ar= e > > > fine in > > > ports, but others like Goran Mekic have opined that they should be > moved > > > to > > > base instead. > > > > > > * musikid's pjdfstest rewrite. I think it would be great to start usi= ng > > > this > > > to test the base system's file systems. If the tests themselves > lived in > > > base, they would be easier to sync with file system development. > > > https://github.com/musikid/pjdfstest > > > > > > * pf-rs. I suspect that the API isn't very stable. > > > https://crates.io/crates/pf-rs > > > > > > * benchpmc. The pmc counter names changes between releases. > > > https://crates.io/crates/benchpmc > > > > > > FreeBSD-related applications that are just fine in ports > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > * fsx-rs. Unlike pjdfstest, this only tests datapath APIs. Those are > > > usually > > > more stable than control path APIs, so I think there's little to be > > > gained by > > > moving this into base. https://crates.io/crates/fsx > > > > > > * ztop. It uses ZFS's kstats sysctl interface, which is pretty stable= . > > > https://crates.io/crates/ztop > > > > > > * iocage-provision https://crates.io/crates/iocage-provision > > > > > > * rsblk https://crates.io/crates/rsblk > > > > > > * xfuse https://github.com/KhaledEmaraDev/xfuse > > > > > > Other FreeBSD-related libraries in Rust > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Just see the list at https://crates.io/keywords/freebsd > > > -- > Tomoaki AOKI <junchoon@dec.sakura.ne.jp> > --000000000000fa7706060f6c5723 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Sat, Jan 20, 2024, 7:06=E2=80=AFPM Tomoaki AOKI <= ;<a href=3D"mailto:junchoon@dec.sakura.ne.jp">junchoon@dec.sakura.ne.jp</a>= > wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, 20 Jan 2024 15:= 31:23 -0700<br> Warner Losh <<a href=3D"mailto:imp@bsdimp.com" target=3D"_blank" rel=3D"= noreferrer">imp@bsdimp.com</a>> wrote:<br> <br> > On Sat, Jan 20, 2024 at 11:45=E2=80=AFAM Aleksandr Fedorov <<a href= =3D"mailto:wigneddoom@yandex.ru" target=3D"_blank" rel=3D"noreferrer">wigne= ddoom@yandex.ru</a>><br> > wrote:<br> > <br> > > What about external dependencies?<br> > ><br> > > <a href=3D"https://github.com/Axcient/freebsd-nfs-exporter/blob/m= aster/Cargo.toml#L19" rel=3D"noreferrer noreferrer" target=3D"_blank">https= ://github.com/Axcient/freebsd-nfs-exporter/blob/master/Cargo.toml#L19</a><b= r> > > <a href=3D"https://github.com/asomers/gstat-rs/blob/master/gstat/= src/main.rs#L20" rel=3D"noreferrer noreferrer" target=3D"_blank">https://gi= thub.com/asomers/gstat-rs/blob/master/gstat/src/main.rs#L20</a><br> > ><br> > > Is there any plan for which crates we should take into the base s= ystem?<br> > ><br> > > We have had C++ in base for many years, but I don=E2=80=99t see a= ny good libraries<br> > > for CLI, logging, JSON, etc.<br> > ><br> > ><br> > > <a href=3D"https://doc.rust-lang.org/rustc/platform-support.html#= tier-1-with-host-tools" rel=3D"noreferrer noreferrer" target=3D"_blank">htt= ps://doc.rust-lang.org/rustc/platform-support.html#tier-1-with-host-tools</= a><br> > ><br> > > Where is the support for Freebsd as a primary platform? ARM, RISC= -V,<br> > > Power? Should we rewrite devd?<br> > ><br> > > I think we need to start by providing official repositories (e.g<= br> > > <a href=3D"http://git.FreeBSD.org/rust.git" rel=3D"noreferrer nor= eferrer" target=3D"_blank">git.FreeBSD.org/rust.git</a> or <a href=3D"http:= //git.FreeBSD.org/go.git" rel=3D"noreferrer noreferrer" target=3D"_blank">g= it.FreeBSD.org/go.git</a>)<br> > > for different languages that include stable bindings to the syste= m API:<br> > > - sysctl<br> > > - libgeom<br> > > - libifconfig<br> > > - netgraph<br> > > - jail<br> > > - etc.<br> > ><br> > > So that it=E2=80=99s not just some anonymous on <a href=3D"http:/= /crates.io" rel=3D"noreferrer noreferrer" target=3D"_blank">crates.io</a> t= hat represents these<br> > > bindings, but our community.<br> > > Officially, with support for a stable ABI for releases, security = patches,<br> > > etc.<br> > ><br> > > After this, it will be possible to think about which components t= o include<br> > > in the base system.<br> > ><br> > > I would be glad to see a more modern language than C in the datab= ase, but<br> > > I=E2=80=99m afraid that it will be like with C++,<br> > > that we will get a couple of daemons and utilities and that=E2=80= =99s all.<br> > ><br> > <br> > These are all good questions that need good answers, though necessaril= y to<br> > get started.<br> > <br> > But the other question that occured to me after my last posting was &q= uot;What<br> > about build integration?"<br> > How much of the rust automation do we take in vs how much do we drive = from<br> > a future <a href=3D"http://bsd.rust.mk" rel=3D"noreferrer noreferrer" = target=3D"_blank">bsd.rust.mk</a>.<br> > I can sketch out <a href=3D"http://bsd.rust.mk" rel=3D"noreferrer nore= ferrer" target=3D"_blank">bsd.rust.mk</a> (to pick an arbitrary name, we= 9;d likely need<br> > one for what we traditionally<br> > think of as libraries (which may or may not map 1:1 onto crates: we co= uld<br> > have c callable libraries<br> > written in rust in the future, for example) and one for binaries.<br> > Initially, though, if we go with the<br> > 'make rust tests possible' then we'd likely need the appro= priate packages<br> > installed for whatever<br> > dependencies we'd have in the tests. This would give us a taste fo= r what<br> > we'd need to do for<br> > base, I'd think. Once we had that notion, I can easily see there n= eeding to<br> > be some sort of<br> > rust bindings for ATF/kyua as one of the first libraries / crates that= <br> > would test that aspect of<br> > the build system. That all would be up to the people writing the tests= in<br> > rust, I'd imagine.<br> > <br> > While I could jot out the basics of this integration (so one could jus= t add<br> > the rust<br> > tools to a subdir or subdirs, include the <a href=3D"http://bsd.rust.m= k" rel=3D"noreferrer noreferrer" target=3D"_blank">bsd.rust.mk</a> or whate= ver and then<br> > it would build<br> > if rust is enabled, and would emit a warning it was skipped because ru= st<br> > was disabled).<br> > We'd find out if this is workable or not and iterate from there. B= ut that<br> > would also require<br> > active participation from the rust advocates to make it a reality: I c= an<br> > put together the<br> > build infrastructure for the disabled case, but likely can't on my= own do<br> > the rust enabled<br> > case. I'd be happy to work with someone to do that, but I'm no= t going to be<br> > able to do<br> > that myself: my need for rust is slight, my knowledge of rust is weak,= etc.<br> > Working with<br> > someone (or ideally several someones), though it could become reality.= So<br> > please contact<br> > me if you'd like to work on this.<br> > <br> > Warner<br> <br> One way to go could be moving programs rewritten with rust to ports.<br> There are some programs (not in rust, though) moved to ports, like rcs.<br>= </blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Yes.= And a number of programs have been made available as ports, but not too ma= ny replace c programs.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><= div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin= :0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Currently, it would not be so realistic, but once we completely switch<br> to pkgbase, IIUC, programs in base can sanely depemd on ports programs,<br> excluding kernel and fundamental libraries.</blockquote></div></div><div di= r=3D"auto"><br></div><div dir=3D"auto">Possible, but I'd wager not for = quite some time for fundamental things. I could be wrong on this timeline..= .</div><div dir=3D"auto"><br></div><div dir=3D"auto"></div><div dir=3D"auto= "><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> As non-rust consumers of graphics/librsvg2-rust can sanely link with<br> it, I assume kmods in ports written in rust can kldload'ed sanely.<br> This could be a good starting point.<br></blockquote></div></div><div dir= =3D"auto"><br></div><div dir=3D"auto">Kernel modules are far off om the hor= izon at this point. There was a proof of concept done years ago, but much h= as changed so an effort is needed to get back to that basic point.</div><di= v dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><bloc= kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc= c solid;padding-left:1ex"> And would be not all, but test for rust libraries could be implemented<br> with C/C++ or any other language suitable, if the rust libraries can<br> sanely linked with test codes.<br></blockquote></div></div><div dir=3D"auto= "><br></div><div dir=3D"auto">That's not a given... ABIs are hard enoug= h without a C to rust layer sneaking in.</div><div dir=3D"auto"><br></div><= div dir=3D"auto">Warner</div><div dir=3D"auto"><br></div><div dir=3D"auto">= <br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D= "gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding= -left:1ex"> Am I wrong?<br> <br> <br> > > 20.01.2024, 19:51, "Alan Somers" <<a href=3D"mailto:= asomers@freebsd.org" target=3D"_blank" rel=3D"noreferrer">asomers@freebsd.o= rg</a>>:<br> > ><br> > > In a recent thread on src-committers, we discussed the costs and<= br> > > benefits of including Rust code in the FreeBSD base system. To<br= > > > summarize, the cost is that it would double our build times. imp<= br> > > suggested adding an additional step after buildworld for stuff th= at<br> > > requires an external toolchain. That would ease the build time pa= in.<br> > > The benefit is that some tools would become easier to write, or e= ven<br> > > become possible. Here is a list of actual and potential Rust proj= ects<br> > > that could benefit from being in-tree. If anybody else has items = to<br> > > add, I suggest moving this into the project wiki:<br> > ><br> > > Stuff that could only be written in Rust if it were in base<br> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> > ><br> > > * ctl-exporter (I started this, but discovered that the CTL stats= API is<br> > >=C2=A0 =C2=A0unstable, so it can't live in ports. Instead, I h= ad to do it in C).<br> > ><br> > > <a href=3D"https://github.com/freebsd/freebsd-src/commit/1a7f22d9= c211f504f6c48a86401469181a67ec34" rel=3D"noreferrer noreferrer" target=3D"_= blank">https://github.com/freebsd/freebsd-src/commit/1a7f22d9c211f504f6c48a= 86401469181a67ec34</a><br> > ><br> > > * fusefs tests. Absolutely impossible to do in C. I considered Ru= st, but<br> > > went<br> > >=C2=A0 =C2=A0with C++ so they could live in base. They are too clo= sely coupled to<br> > >=C2=A0 =C2=A0fusefs(5) to live out-of-tree.<br> > >=C2=A0 =C2=A0<a href=3D"https://github.com/freebsd/freebsd-src/tre= e/main/tests/sys/fs/fusefs" rel=3D"noreferrer noreferrer" target=3D"_blank"= >https://github.com/freebsd/freebsd-src/tree/main/tests/sys/fs/fusefs</a><b= r> > ><br> > > * devd. Currently C++, but imp suggested a rewrite.<br> > >=C2=A0 =C2=A0<a href=3D"https://github.com/freebsd/freebsd-src/tre= e/main/sbin/devd" rel=3D"noreferrer noreferrer" target=3D"_blank">https://g= ithub.com/freebsd/freebsd-src/tree/main/sbin/devd</a><br> > ><br> > > * zfsd. Currently C++, but I've long pondered a rewrite. Usin= g Rust would<br> > >=C2=A0 =C2=A0make it more testable.<br> > >=C2=A0 =C2=A0<a href=3D"https://github.com/freebsd/freebsd-src/tre= e/main/cddl/usr.sbin/zfsd" rel=3D"noreferrer noreferrer" target=3D"_blank">= https://github.com/freebsd/freebsd-src/tree/main/cddl/usr.sbin/zfsd</a><br>; > ><br> > > * nscd. Currently C, but confusing and with no test coverage. I&#= 39;ve<br> > >=C2=A0 =C2=A0contemplated a rewrite myself, but I don't want t= o do it in C.<br> > >=C2=A0 =C2=A0<a href=3D"https://github.com/freebsd/freebsd-src/tre= e/main/usr.sbin/nscd" rel=3D"noreferrer noreferrer" target=3D"_blank">https= ://github.com/freebsd/freebsd-src/tree/main/usr.sbin/nscd</a><br> > ><br> > > * The userland portion of the 802.11ac and Lightning stacks. scot= tl<br> > > suggested<br> > >=C2=A0 =C2=A0that these were good candidates for Rust.<br> > ><br> > > * freebsd-kpi-r14-0 . <a href=3D"https://crates.io/crates/freebsd= -kpi-r14-0" rel=3D"noreferrer noreferrer" target=3D"_blank">https://crates.= io/crates/freebsd-kpi-r14-0</a><br> > ><br> > > Stuff that can live in ports, but would be nicer in base<br> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> > ><br> > > * gstat-rs <a href=3D"https://crates.io/crates/gstat" rel=3D"nore= ferrer noreferrer" target=3D"_blank">https://crates.io/crates/gstat</a><br>; > ><br> > > * geom-exporter (I've started this, but haven't published= it)<br> > ><br> > > * nfs-exporter <a href=3D"https://crates.io/crates/freebsd-nfs-ex= porter" rel=3D"noreferrer noreferrer" target=3D"_blank">https://crates.io/c= rates/freebsd-nfs-exporter</a><br> > ><br> > > * virtiofsd-rs . Nobody has yet tried to port it to FreeBSD. But = if the<br> > >=C2=A0 =C2=A0connection to bhyve(8) is too intimate, it might be h= ard to do in ports.<br> > >=C2=A0 =C2=A0<a href=3D"https://gitlab.com/virtio-fs/virtiofsd" re= l=3D"noreferrer noreferrer" target=3D"_blank">https://gitlab.com/virtio-fs/= virtiofsd</a><br> > ><br> > > * jail-exporter <a href=3D"https://crates.io/crates/jail_exporter= " rel=3D"noreferrer noreferrer" target=3D"_blank">https://crates.io/crates/= jail_exporter</a><br> > ><br> > > * Various jail managers have been attempted in Rust. I think thes= e are<br> > > fine in<br> > >=C2=A0 =C2=A0ports, but others like Goran Mekic have opined that t= hey should be moved<br> > > to<br> > >=C2=A0 =C2=A0base instead.<br> > ><br> > > * musikid's pjdfstest rewrite. I think it would be great to s= tart using<br> > > this<br> > >=C2=A0 =C2=A0to test the base system's file systems. If the te= sts themselves lived in<br> > >=C2=A0 =C2=A0base, they would be easier to sync with file system d= evelopment.<br> > >=C2=A0 =C2=A0<a href=3D"https://github.com/musikid/pjdfstest" rel= =3D"noreferrer noreferrer" target=3D"_blank">https://github.com/musikid/pjd= fstest</a><br> > ><br> > > * pf-rs. I suspect that the API isn't very stable.<br> > >=C2=A0 =C2=A0<a href=3D"https://crates.io/crates/pf-rs" rel=3D"nor= eferrer noreferrer" target=3D"_blank">https://crates.io/crates/pf-rs</a><br= > > ><br> > > * benchpmc. The pmc counter names changes between releases.<br> > >=C2=A0 =C2=A0<a href=3D"https://crates.io/crates/benchpmc" rel=3D"= noreferrer noreferrer" target=3D"_blank">https://crates.io/crates/benchpmc<= /a><br> > ><br> > > FreeBSD-related applications that are just fine in ports<br> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> > ><br> > > * fsx-rs. Unlike pjdfstest, this only tests datapath APIs. Those = are<br> > > usually<br> > >=C2=A0 =C2=A0more stable than control path APIs, so I think there&= #39;s little to be<br> > > gained by<br> > >=C2=A0 =C2=A0moving this into base. <a href=3D"https://crates.io/c= rates/fsx" rel=3D"noreferrer noreferrer" target=3D"_blank">https://crates.i= o/crates/fsx</a><br> > ><br> > > * ztop. It uses ZFS's kstats sysctl interface, which is prett= y stable.<br> > >=C2=A0 =C2=A0<a href=3D"https://crates.io/crates/ztop" rel=3D"nore= ferrer noreferrer" target=3D"_blank">https://crates.io/crates/ztop</a><br>; > ><br> > > * iocage-provision <a href=3D"https://crates.io/crates/iocage-pro= vision" rel=3D"noreferrer noreferrer" target=3D"_blank">https://crates.io/c= rates/iocage-provision</a><br> > ><br> > > * rsblk <a href=3D"https://crates.io/crates/rsblk" rel=3D"norefer= rer noreferrer" target=3D"_blank">https://crates.io/crates/rsblk</a><br>; > ><br> > > * xfuse <a href=3D"https://github.com/KhaledEmaraDev/xfuse" rel= =3D"noreferrer noreferrer" target=3D"_blank">https://github.com/KhaledEmara= Dev/xfuse</a><br> > ><br> > > Other FreeBSD-related libraries in Rust<br> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> > > Just see the list at <a href=3D"https://crates.io/keywords/freebs= d" rel=3D"noreferrer noreferrer" target=3D"_blank">https://crates.io/keywor= ds/freebsd</a><br> <br> <br> -- <br> Tomoaki AOKI=C2=A0 =C2=A0 <<a href=3D"mailto:junchoon@dec.sakura.ne.jp" = target=3D"_blank" rel=3D"noreferrer">junchoon@dec.sakura.ne.jp</a>><br> </blockquote></div></div></div> --000000000000fa7706060f6c5723--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfprPW2NOZaRCQJqFao3oKaJVE-ToHB-wVyBegLYkR3HRw>