Date: Sat, 3 Aug 2024 11:36:52 -0600 From: Warner Losh <imp@bsdimp.com> To: Shawn Webb <shawn.webb@hardenedbsd.org> Cc: 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: <CANCZdfoHjYUDeNo78qk6BjHfRgwgDbuuVjD5D9uG6tyCk81-ew@mail.gmail.com> In-Reply-To: <knnsh327gxyvaajwrymvflnivf3tsnigyqw2d6etfhb4irft3x@ydkh3zmb6uch> References: <CAOtMX2hAUiWdGPtpaCJLPZB%2Bj2yzNw5DSjUmkwTi%2B%2BmyemehCA@mail.gmail.com> <vdmg5zocd6wqcwc2bvzvzqn4bii2pwdc2r4mgnisukfkboj6nf@f7lv5quu4fjx> <CAOtMX2iDK3uN_oQgzzZAdoOZCfNsnvpefeZvKoTCRmPBhZywzA@mail.gmail.com> <CANCZdfqB1%2B-8BkpKwKoCM%2BzM4mCOFy63yHr1Pco7MnT1DFkb4w@mail.gmail.com> <knnsh327gxyvaajwrymvflnivf3tsnigyqw2d6etfhb4irft3x@ydkh3zmb6uch>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Wed, Jul 31, 2024 at 12:51 PM Shawn Webb <shawn.webb@hardenedbsd.org> wrote: > On Wed, Jul 31, 2024 at 11:01:17AM -0600, Warner Losh wrote: > > On Wed, Jul 31, 2024, 9:40 AM Alan Somers <asomers@freebsd.org> wrote: > > > > > On Wed, Jul 31, 2024 at 8:37 AM Shawn Webb <shawn.webb@hardenedbsd.org > > > > > wrote: > > > > > > > > On Sat, Jan 20, 2024 at 09:51:25AM -0700, Alan Somers wrote: > > > > > 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 > > > > > =========================================================== > > > > > > > > > > * 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/1a7f22d9c211f504f6c48a86401469181a67ec34 > > > > > > > > > > * 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 > > > > > > > > > > * 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 > > > > > ======================================================== > > > > > > > > > > * 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 > > > the > > > > > 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 > > > are 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 > > > 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 > > > > > > > > > > * 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 > > > > > ========================================================= > > > > > > > > > > * 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 > > > > > ======================================= > > > > > Just see the list at https://crates.io/keywords/freebsd > > > > > > > > > > > > > One new data point: DARPA is looking to rewrite a significant amount > > > > of C code to Rust with their "Translating All C to Rust (TRACTOR)" > > > > project: > > > > https://sam.gov/opp/1e45d648886b4e9ca91890285af77eb7/view > > > > > > Interesting. And since you bring it up, I have two new data points > myself: > > > > > > * ctld: while working on some bugs in ctld, I had trouble > > > understanding the config file parsing. So I rewrote that part in > > > Rust, just to help my understanding. Later, I rewrote the XML > > > parsing, too. Then I rewrote the LUN creation and deletion, just to > > > see how hard it would be. All of those parts take about 5x fewer SLOC > > > in Rust than in C, and they're less buggy, too. Config file parsing > > > is more consistent, no memory leaks, etc. Alas, I'm not planning to > > > finish this project, since the base system doesn't allow Rust and ctld > > > is too tightly coupled to ctl to live in ports. > > > > > > > Cool. Still waiting for anybody to take me up on the offer to do build > > system integration. Since the Rust advocates can't get even this basic > step > > done for review, it's going to be impossible to have Rust in the base. > This > > isn't even integrate rust compiler like we do with llvm, but with > external > > Rust toolchain. > > > > Until somebody steps up for this task, the status quo can't possibly > change. > > Back at the FreeBSD Developer Summit at this last BSDCan, there was > interest in supporting optional external toolchains in the src build > framework. You had mentioned you would be happy to mentor someone, but > not do the nitty gritty yourself. > Yes. I've made that offer half a dozen times now. > I could carve off some time in September to be the primary developer, > doing the nitty gritty work. Would you be comfortable answering my > questions, should I have any? > You bet. I'd love to see progress made on this front. But I'm in Ireland on vacation half the month, so there may be timing issues. Other than that, I'm happy. > Also: what work (or research), if any, has been done on the concept of > external toolchain support for optional components in the FreeBSD > source tree? Am I starting afresh or building upon existing work? > We already have clang and gcc external tool chains, so there's a proven mechanism for that. But there's not a good notion of the concept "I have a rust compiler" or "I depend on rust". And there's no concept of crates or similar that rust programs use, but that will be one thorny area that we'll have to design for. Do we just pull them in and junk any notion of a reproducible build for these components into the future (since any crate can go away), or do we have a way to build up our own set of crates in the tree that the optional components depend on. How do we do change management on that if we have multiple programs that depend on a crate that's updated? how do we keep things fresh while not having update cascades be too burdensome a task. How does this tie into pkgbase? These are the things to think about. We don't need to solve all of them, but the Rust ecosystem is quite a bit different than the C ecosystem in the details of a number of these points, so we have to address them if we want to use Rust in base with the same traits as all the other bits in base today (or we need to have a thoughtful discussion on paradigm shift and settle on that). To my thinking, pkgbase might be a good way to segregate crates that are build from the base tree and express dependencies on optional components that use it, and have the ultimate dependency be a pkg from ports. These questions and design points aren't hard and aren't designed to block anything, but a bare minimum of what we need to articulate is the vision for these components. Likely a design document that spells these out in some degree of detail (or that we punt in this phase) would be good as well. I can help with that as well. Warner > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 31, 2024 at 12:51 PM Shawn Webb <<a href="mailto:shawn.webb@hardenedbsd.org">shawn.webb@hardenedbsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jul 31, 2024 at 11:01:17AM -0600, Warner Losh wrote:<br> > On Wed, Jul 31, 2024, 9:40 AM Alan Somers <<a href="mailto:asomers@freebsd.org" target="_blank">asomers@freebsd.org</a>> wrote:<br> > <br> > > On Wed, Jul 31, 2024 at 8:37 AM Shawn Webb <<a href="mailto:shawn.webb@hardenedbsd.org" target="_blank">shawn.webb@hardenedbsd.org</a>><br> > > wrote:<br> > > ><br> > > > On Sat, Jan 20, 2024 at 09:51:25AM -0700, Alan Somers wrote:<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 that<br> > > > > requires an external toolchain. That would ease the build time pain.<br> > > > > The benefit is that some tools would become easier to write, or even<br> > > > > become possible. Here is a list of actual and potential Rust projects<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> > > > > ===========================================================<br> > > > ><br> > > > > * ctl-exporter (I started this, but discovered that the CTL stats API<br> > > is<br> > > > > unstable, so it can't live in ports. Instead, I had to do it in C).<br> > > > ><br> > > <a href="https://github.com/freebsd/freebsd-src/commit/1a7f22d9c211f504f6c48a86401469181a67ec34" rel="noreferrer" target="_blank">https://github.com/freebsd/freebsd-src/commit/1a7f22d9c211f504f6c48a86401469181a67ec34</a><br>; > > > ><br> > > > > * fusefs tests. Absolutely impossible to do in C. I considered Rust,<br> > > but went<br> > > > > with C++ so they could live in base. They are too closely coupled to<br> > > > > fusefs(5) to live out-of-tree.<br> > > > > <a href="https://github.com/freebsd/freebsd-src/tree/main/tests/sys/fs/fusefs" rel="noreferrer" target="_blank">https://github.com/freebsd/freebsd-src/tree/main/tests/sys/fs/fusefs</a><br>; > > > ><br> > > > > * devd. Currently C++, but imp suggested a rewrite.<br> > > > > <a href="https://github.com/freebsd/freebsd-src/tree/main/sbin/devd" rel="noreferrer" target="_blank">https://github.com/freebsd/freebsd-src/tree/main/sbin/devd</a><br>; > > > ><br> > > > > * zfsd. Currently C++, but I've long pondered a rewrite. Using Rust<br> > > would<br> > > > > make it more testable.<br> > > > > <a href="https://github.com/freebsd/freebsd-src/tree/main/cddl/usr.sbin/zfsd" rel="noreferrer" target="_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've<br> > > > > contemplated a rewrite myself, but I don't want to do it in C.<br> > > > > <a href="https://github.com/freebsd/freebsd-src/tree/main/usr.sbin/nscd" rel="noreferrer" target="_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. scottl<br> > > suggested<br> > > > > that these were good candidates for Rust.<br> > > > ><br> > > > > * freebsd-kpi-r14-0 . <a href="https://crates.io/crates/freebsd-kpi-r14-0" rel="noreferrer" target="_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> > > > > ========================================================<br> > > > ><br> > > > > * gstat-rs <a href="https://crates.io/crates/gstat" rel="noreferrer" target="_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="https://crates.io/crates/freebsd-nfs-exporter" rel="noreferrer" target="_blank">https://crates.io/crates/freebsd-nfs-exporter</a><br>; > > > ><br> > > > > * virtiofsd-rs . Nobody has yet tried to port it to FreeBSD. But if<br> > > the<br> > > > > connection to bhyve(8) is too intimate, it might be hard to do in<br> > > ports.<br> > > > > <a href="https://gitlab.com/virtio-fs/virtiofsd" rel="noreferrer" target="_blank">https://gitlab.com/virtio-fs/virtiofsd</a><br>; > > > ><br> > > > > * jail-exporter <a href="https://crates.io/crates/jail_exporter" rel="noreferrer" target="_blank">https://crates.io/crates/jail_exporter</a><br>; > > > ><br> > > > > * Various jail managers have been attempted in Rust. I think these<br> > > are fine in<br> > > > > ports, but others like Goran Mekic have opined that they should be<br> > > moved to<br> > > > > base instead.<br> > > > ><br> > > > > * musikid's pjdfstest rewrite. I think it would be great to start<br> > > using this<br> > > > > to test the base system's file systems. If the tests themselves<br> > > lived in<br> > > > > base, they would be easier to sync with file system development.<br> > > > > <a href="https://github.com/musikid/pjdfstest" rel="noreferrer" target="_blank">https://github.com/musikid/pjdfstest</a><br>; > > > ><br> > > > > * pf-rs. I suspect that the API isn't very stable.<br> > > > > <a href="https://crates.io/crates/pf-rs" rel="noreferrer" target="_blank">https://crates.io/crates/pf-rs</a><br>; > > > ><br> > > > > * benchpmc. The pmc counter names changes between releases.<br> > > > > <a href="https://crates.io/crates/benchpmc" rel="noreferrer" target="_blank">https://crates.io/crates/benchpmc</a><br>; > > > ><br> > > > > FreeBSD-related applications that are just fine in ports<br> > > > > =========================================================<br> > > > ><br> > > > > * fsx-rs. Unlike pjdfstest, this only tests datapath APIs. Those are<br> > > usually<br> > > > > more stable than control path APIs, so I think there's little to be<br> > > gained by<br> > > > > moving this into base. <a href="https://crates.io/crates/fsx" rel="noreferrer" target="_blank">https://crates.io/crates/fsx</a><br>; > > > ><br> > > > > * ztop. It uses ZFS's kstats sysctl interface, which is pretty stable.<br> > > > > <a href="https://crates.io/crates/ztop" rel="noreferrer" target="_blank">https://crates.io/crates/ztop</a><br>; > > > ><br> > > > > * iocage-provision <a href="https://crates.io/crates/iocage-provision" rel="noreferrer" target="_blank">https://crates.io/crates/iocage-provision</a><br>; > > > ><br> > > > > * rsblk <a href="https://crates.io/crates/rsblk" rel="noreferrer" target="_blank">https://crates.io/crates/rsblk</a><br>; > > > ><br> > > > > * xfuse <a href="https://github.com/KhaledEmaraDev/xfuse" rel="noreferrer" target="_blank">https://github.com/KhaledEmaraDev/xfuse</a><br>; > > > ><br> > > > > Other FreeBSD-related libraries in Rust<br> > > > > =======================================<br> > > > > Just see the list at <a href="https://crates.io/keywords/freebsd" rel="noreferrer" target="_blank">https://crates.io/keywords/freebsd</a><br>; > > > ><br> > > ><br> > > > One new data point: DARPA is looking to rewrite a significant amount<br> > > > of C code to Rust with their "Translating All C to Rust (TRACTOR)"<br> > > > project:<br> > > > <a href="https://sam.gov/opp/1e45d648886b4e9ca91890285af77eb7/view" rel="noreferrer" target="_blank">https://sam.gov/opp/1e45d648886b4e9ca91890285af77eb7/view</a><br>; > ><br> > > Interesting. And since you bring it up, I have two new data points myself:<br> > ><br> > > * ctld: while working on some bugs in ctld, I had trouble<br> > > understanding the config file parsing. So I rewrote that part in<br> > > Rust, just to help my understanding. Later, I rewrote the XML<br> > > parsing, too. Then I rewrote the LUN creation and deletion, just to<br> > > see how hard it would be. All of those parts take about 5x fewer SLOC<br> > > in Rust than in C, and they're less buggy, too. Config file parsing<br> > > is more consistent, no memory leaks, etc. Alas, I'm not planning to<br> > > finish this project, since the base system doesn't allow Rust and ctld<br> > > is too tightly coupled to ctl to live in ports.<br> > ><br> > <br> > Cool. Still waiting for anybody to take me up on the offer to do build<br> > system integration. Since the Rust advocates can't get even this basic step<br> > done for review, it's going to be impossible to have Rust in the base. This<br> > isn't even integrate rust compiler like we do with llvm, but with external<br> > Rust toolchain.<br> > <br> > Until somebody steps up for this task, the status quo can't possibly change.<br> <br> Back at the FreeBSD Developer Summit at this last BSDCan, there was<br> interest in supporting optional external toolchains in the src build<br> framework. You had mentioned you would be happy to mentor someone, but<br> not do the nitty gritty yourself.<br></blockquote><div><br></div><div>Yes. I've made that offer half a dozen times now.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I could carve off some time in September to be the primary developer,<br> doing the nitty gritty work. Would you be comfortable answering my<br> questions, should I have any?<br></blockquote><div><br></div><div>You bet. I'd love to see progress made on this front. But I'm in Ireland</div><div>on vacation half the month, so there may be timing issues. Other than that,</div><div>I'm happy.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Also: what work (or research), if any, has been done on the concept of<br> external toolchain support for optional components in the FreeBSD<br> source tree? Am I starting afresh or building upon existing work?<br></blockquote><div><br></div><div>We already have clang and gcc external tool chains, so there's a proven</div><div>mechanism for that. But there's not a good notion of the concept "I have</div><div>a rust compiler" or "I depend on rust". And there's no concept of crates</div><div>or similar that rust programs use, but that will be one thorny area that</div><div>we'll have to design for. Do we just pull them in and junk any notion of</div><div>a reproducible build for these components into the future (since any crate</div><div>can go away), or do we have a way to build up our own set of crates</div><div>in the tree that the optional components depend on. How do we do change</div><div>management on that if we have multiple programs that depend on a crate</div><div>that's updated? how do we keep things fresh while not having update</div><div>cascades be too burdensome a task. How does this tie into pkgbase?</div><div><br></div><div>These are the things to think about. We don't need to solve all of</div><div>them, but the Rust ecosystem is quite a bit different than the C ecosystem</div><div>in the details of a number of these points, so we have to address them</div><div>if we want to use Rust in base with the same traits as all the other bits</div><div>in base today (or we need to have a thoughtful discussion on paradigm</div><div>shift and settle on that). To my thinking, pkgbase might be a good way</div><div>to segregate crates that are build from the base tree and express dependencies</div><div>on optional components that use it, and have the ultimate dependency</div><div>be a pkg from ports. <br></div><div><br></div><div>These questions and design points aren't hard and aren't designed to</div><div>block anything, but a bare minimum of what we need to articulate is the</div><div>vision for these components. Likely a design document that spells these</div><div>out in some degree of detail (or that we punt in this phase) would be good</div><div>as well. I can help with that as well.<br></div><div><br></div><div>Warner<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Thanks,<br> <br> -- <br> Shawn Webb<br> Cofounder / Security Engineer<br> HardenedBSD<br> <br> Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50<br> <a href="https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc" rel="noreferrer" target="_blank">https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc</a><br>; </blockquote></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoHjYUDeNo78qk6BjHfRgwgDbuuVjD5D9uG6tyCk81-ew>