version binfmt wire format #103
Conversation
binfmt.x contains the target side version; this version will be stored in the ELF `binfmt_decoder` will check that the version stored in the ELF matches the version it supports (`BINFMT_VERSION` const in `binfmt_decoder` crate)
| let mut hasher = DefaultHasher::new(); | ||
| let output = Command::new("git") | ||
| .args(&["rev-parse", "HEAD"]) | ||
| .output()?; |
There was a problem hiding this comment.
So this won't work with the crates.io version, we'd need some kind of fallback when the git command fails that will use the package version instead (same in decoder/build.rs). Feel free to merge without that though, and maybe open an issue to keep track of this.
There was a problem hiding this comment.
Yes, for crates.io releases we should use e.g. hash32of("0.1.0-alpha.1"), instead of the git commit hash, and update those version strings for as long as we intend to make breaking changes (until 1.0). That should be part of the release process; is that canonically documented somewhere? e.g. /RELEASE.md
There was a problem hiding this comment.
I don't think it needs to be manual, Cargo sets CARGO_PKG_VERSION to the version string when running the build script. We just need to make sure the versions match.
binfmt.x contains the target side version; this version will be stored in the
ELF
binfmt_decoderwill check that the version stored in the ELF matches theversion it supports (
BINFMT_VERSIONconst inbinfmt_decodercrate)TODO
git rev-parse --short HEAD(32-bit hash of) to catch mismatch betweencargo install --gittools andbinfmtused as agitdependency(meant to open this as a draft PR but I can't?)