Date: Sat, 20 Jan 2024 21:54:18 +0400 From: Antranig Vartanian <antranigv@freebsd.am> To: Alan Somers <asomers@freebsd.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, Warner Losh <imp@bsdimp.com>, Scott Long <scottl@freebsd.org>, =?utf-8?Q?Goran_Meki=C4=87?= <meka@tilda.center> Subject: Re: The Case for Rust (in the base system) Message-ID: <CAFF117C-4E6B-4339-8A9A-391ED720C508@freebsd.am> In-Reply-To: <CAOtMX2hAUiWdGPtpaCJLPZB%2Bj2yzNw5DSjUmkwTi%2B%2BmyemehCA@mail.gmail.com> References: <CAOtMX2hAUiWdGPtpaCJLPZB%2Bj2yzNw5DSjUmkwTi%2B%2BmyemehCA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I don=E2=80=99t want to do a what-aboutism, but if all we=E2=80=99re = looking for is a good and=20 secure system programming language, the alternatives are nicer. There=E2=80=99s Modula-3, which, unlike Rust, supported FreeBSD as Tier = 1, I=E2=80=99m sure the=20 compiler is smaller, although hasn=E2=80=99t been updated in a while. On that thought, Wirth=E2=80=99s passing reminded me of Oberon-2, which = does have a=20 port on FreeBSD, lang/voc. It can also =E2=80=9Cattach=E2=80=9D to the C = functions. Last year I=20 integrated libxo, libucl and libjail with Oberon-2/VOC and it all worked = fine. The compile times are also impressive.[1][2] However, if all we=E2=80=99re looking for is to be fancy and follow the = industry, Rust=20 doesn=E2=80=99t seem bad overall. The main issue is the toolchain. 2x = compile time=20 would be awful. Optional targets would be nice, but then people will = start=20 writing X/Y/Z in Rust, and before you know jail(8) would start requiring = a=20 large external compiler. Again, to be clear, I would like to hear the =E2=80=9Cwhy=E2=80=9D more = than the =E2=80=9Chow=E2=80=9D. 1: https://github.com/antranigv/voclibucl 2: https://github.com/antranigv/voclibxo=20 Cheers, =E2=80=94 Antranig Vartanian https://antranigv.am/ PGP Key ID: 0x2D59F21C > On 20 Jan 2024, at 8:51=E2=80=AFPM, Alan Somers <asomers@freebsd.org> = wrote: >=20 > 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: >=20 > 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 >=20 > * 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/1a7f22d9c211f504f6c48a864014= 69181a67ec34 >=20 > * 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 to > fusefs(5) to live out-of-tree. > https://github.com/freebsd/freebsd-src/tree/main/tests/sys/fs/fusefs >=20 > * devd. Currently C++, but imp suggested a rewrite. > https://github.com/freebsd/freebsd-src/tree/main/sbin/devd >=20 > * 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 >=20 > * 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 >=20 > * The userland portion of the 802.11ac and Lightning stacks. scottl = suggested > that these were good candidates for Rust. >=20 > * freebsd-kpi-r14-0 . https://crates.io/crates/freebsd-kpi-r14-0 >=20 > 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 >=20 > * gstat-rs https://crates.io/crates/gstat >=20 > * geom-exporter (I've started this, but haven't published it) >=20 > * nfs-exporter https://crates.io/crates/freebsd-nfs-exporter >=20 > * virtiofsd-rs . Nobody has yet tried to port it to FreeBSD. But if = the > connection to bhyve(8) is too intimate, it might be hard to do in = ports. > https://gitlab.com/virtio-fs/virtiofsd >=20 > * jail-exporter https://crates.io/crates/jail_exporter >=20 > * Various jail managers have been attempted in Rust. I think these = are fine in > ports, but others like Goran Mekic have opined that they should be = moved to > base instead. >=20 > * musikid's pjdfstest rewrite. I think it would be great to start = using 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 >=20 > * pf-rs. I suspect that the API isn't very stable. > https://crates.io/crates/pf-rs >=20 > * benchpmc. The pmc counter names changes between releases. > https://crates.io/crates/benchpmc >=20 > 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 >=20 > * 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 >=20 > * ztop. It uses ZFS's kstats sysctl interface, which is pretty = stable. > https://crates.io/crates/ztop >=20 > * iocage-provision https://crates.io/crates/iocage-provision >=20 > * rsblk https://crates.io/crates/rsblk >=20 > * xfuse https://github.com/KhaledEmaraDev/xfuse >=20 > 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 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFF117C-4E6B-4339-8A9A-391ED720C508>