From nobody Sat Jan 20 17:54:18 2024 X-Original-To: freebsd-hackers@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 4THPJB68GWz56NdM for ; Sat, 20 Jan 2024 17:54:34 +0000 (UTC) (envelope-from antranigv@freebsd.am) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4THPJB5bhsz4QWK; Sat, 20 Jan 2024 17:54:34 +0000 (UTC) (envelope-from antranigv@freebsd.am) Authentication-Results: mx1.freebsd.org; none Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3EB935C00BD; Sat, 20 Jan 2024 12:54:34 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sat, 20 Jan 2024 12:54:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.am; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1705773274; x=1705859674; bh=q2OI8LQeW9ataLmdcWAMybTj2M2Sw5U5Q4ZMTM9uNuc=; b= 1j1YAy2hMCYAqsG4HJPkg7PNlrPs9VHT2ocEYmZn3MrYumOr7FB60d5tii8lXeZ1 KN/nPedIoAPJZgBfR0Ss3G/I7xuJnr1ujupNCamHxzoDgZjRWRz0M103oZmqVvY9 Kj+k8Co1sse1r7oxf3LksAJBzpqVh/4nUh7ReXh6XBekyKPa8llDZj6tbBB/FGde 4awMq3e0Hue9AtXyBlFBwF9jKZm7bLsObdoAZR9wKvqBWK72tBIM4MHR2fJ5praU nl+AGIdr+vr1+KR21/wNwkKvPi4SUisohKJfwrSc2UOdLb5cf4C/eT2/sYmtVq0h 3oKneZQDnHJFKgo7LbIDRg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705773274; x= 1705859674; bh=q2OI8LQeW9ataLmdcWAMybTj2M2Sw5U5Q4ZMTM9uNuc=; b=E 0RpSzGPqCxhLNvrj5duK3iM6DqBC3X14wI7YLaBcyXL+poeWBlDXucifSMnVGRCz 33WGIxMAZ4sjywAPFkseCUUnXqO/Get8GEapsLnFGSulF9LhCUchnd14RUAHTrPN VxRnglSMw9Z3ZJ7zDZEdNrtxE5Afb3cgdXM9+dBhT1oYHoeE6G9vGjSmJW3okfCh KCcM11Ga1mUq7J9KSu1zsYRLrZ+UTClF2igOuWKNIQ5ZkuHBEsg/lqfUKOCbsc8D YZZneI8NimsFU3ZiiBfiZBPwwHwIJQH9Bgv2Ez0p0cMbaBIMH0GV1hVOWsn9e0aa v2zTkwF1A6DF0Si9wW++g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdekvddguddtjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjffevgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehn thhrrghnihhgucggrghrthgrnhhirghnuceorghnthhrrghnihhgvhesfhhrvggvsghsug drrghmqeenucggtffrrghtthgvrhhnpefgudffteelleetheejffekfffftefhleehgefh uedtgfdthedvudetieejfeekgfenucffohhmrghinhepghhithhhuhgsrdgtohhmpdgrnh htrhgrnhhighhvrdgrmhdptghrrghtvghsrdhiohdpghhithhlrggsrdgtohhmnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghnthhrrghnih hgvhesfhhrvggvsghsugdrrghm X-ME-Proxy: Feedback-ID: ibc494664:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 20 Jan 2024 12:54:31 -0500 (EST) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: The Case for Rust (in the base system) From: Antranig Vartanian In-Reply-To: Date: Sat, 20 Jan 2024 21:54:18 +0400 Cc: FreeBSD Hackers , Warner Losh , Scott Long , =?utf-8?Q?Goran_Meki=C4=87?= Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alan Somers X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Rspamd-Queue-Id: 4THPJB5bhsz4QWK 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:19151, ipnet:66.111.4.0/24, country:US] 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 = 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