Add options for reproducible builds.

[boomshroom]

Thanks to tools like Cargo.lock, --frozen, and cargo-vendor, it's possible to make fully reproducible builds. I propose allowing bootimage to take advantage to these tools to allow for reproducible boot images.

The main changes that would need to take place for this would be adding the ability to specify the bootloader url or git revision, and letting the user pass --frozen to the underlying calls to cargo and xargo.

[phil-opp]

Sounds like a good addition! I don't have time to do this myself, but pull requests are welcome!

@lachlansneff You also had some ideas of extending the bootimage tool. What do you think about this?

[boomshroom]

I suppose one question would be whether we want an option that passes arbitrary arguments to xargo, pass all arguments that bootimage doesn't parse to xargo, or add --frozen as an explicit parameter to bootimage.

For specifying the bootloader, there is a variety of ways to implement it. Some options include giving a local file path and assume the user will download it before hand should they wish to pin it, or add a commit hash to the existing git parameter. There's also the question of whether or not this should point to the source or build of the bootloader.

The current options for the bootloader are

• Download the latest prebuilt and exit
• Clone the source from master at an arbitrary git repo, build and exit
• Preform one of the previous and link the kernel

Which of these options seem more appealing?

[boomshroom]

Looking at the xargo source code, it appears as though it does support setting the source directory with XARGO_RUST_SRC.

[phil-opp]

Looking at the xargo source code, it appears as though it does support setting the source directory with XARGO_RUST_SRC.

Cool!

I suppose one question would be whether we want an option that passes arbitrary arguments to xargo, pass all arguments that bootimage doesn't parse to xargo, or add --frozen as an explicit parameter to bootimage.

I'm not sure. Passing all arguments to xargo would make it more flexible, but there might be some options that break the build (e.g. by changing the target directory). So I think passing only --frozen is the better short-term solution. For the long term, we should find a way of integrating more deeply with cargo, e.g. through the cargo crate or via build scripts (this would require build scripts that run after compilation).

For specifying the bootloader, there is a variety of ways to implement it.

We should provide options for overriding the default download URL, the release name (latest at the moment, but some kind of version number when it becomes more stable), and the repository URL. Allowing a local bootloader also seems useful.