Hi

From https://go.dev/blog/compat "Go programs that work today should continue to work even as future releases of Go 1 arise."

A minimal version can be specified in the go.mod file. As go is only used in tooling and that the output is specified to not depend on the version.

The benefit of caring about reproducibility of the go toolchain and its outputs is IMO less important.
Also getting the right toolchain might just become a trivial issue in the future: https://go.dev/blog/toolchain . Rustup worked like that for some time.

For rust I'd recommend making rustup a dependency. You can specify a toolchain version which the rust code should automatically take care of reproducibility.

Getting the 'right compiler' is a trivial issue in rust, so I'd add no explicit dealing except by what is provided by the package manager (cargo).

Getting rustup is a one-liner btw, it's a cool tool!

About rust in coreboot. I like it a lot! The tooling is excellent and makes importing new code a bliss compared to C. The language itself has a steep learning curve, but is very elegant once you know it in my opinion.

I already linked some rust code into a coreboot stage and wrote a blog post about it: https://blog.aheymans.xyz/rust_coreboot.html

I believe a proper integration of rust is a very achievable goal.

1. Currently we have a chain of trust:
    * our Git repository and the checked out commit (hash)
    * hashes for files to download (e.g. for the GCC sources)
      - those are checked into the repository
    If we surrender the control about what to download (and install
    and run) to another program, we should probably warn the user.
    I had a quick look at `rustup` and `cargo` and couldn't find an
    answer if things can be specified by hash. I hope they can.

Is rustup-init the anwser? https://rust-lang.github.io/rustup/installation/other.html has hashes?

 

Arthur

On Fri, Nov 3, 2023 at 12:19 AM Martin Roth via coreboot <coreboot@coreboot.org> wrote:

I'm proposing that we look at adding Go and Rust to the coreboot toolchain.

Go:
We’re already using a number of things written in Go as a part of the build, and they currently use the system toolchain, leaving droppings outside of the coreboot and $obj folders as a part of the build. Additionally, we want the binary we produce to be reproducible - I’m not sure if that’s currently a problem or not. SBOM, STM

Rust:
Rust is starting to be used more and more widely as a system programming language. The Linux kernel is accepting Rust. Oxide’s entire codebase is in Rust. The Oreboot project is using Rust. While I’m not personally a fan of Rust, I can see the need to support it coming.
Ron has already posted a patch to add Rust support, but I think it needs to be reworked so that everything is contained in the XGCC directory, has a stable version for coreboot, and doesn't conflict with any system tools.
https://review.coreboot.org/c/coreboot/+/74124


Neither of these is particularly urgent in my opinion, but I want to get the discussion started. I've added this as a topic to the next coreboot leadership meeting.

Martin
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org