<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 3 May 2020, 07:40 Michael Brown, <<a href="mailto:mcb30@ipxe.org">mcb30@ipxe.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 01/05/2020 23:36, Neil Roza wrote:<br>
> Please find the attached diff representing a patch I would like to <br>
> submit for your consideration. This is a small change to the <br>
> `src/Makefile.housekeeping` that makes the generation of most artifacts <br>
> (notably not `*.usb` images) deterministic.<br>
> <br>
> The scariest change here is the removal of the `BUILD_ID_CMD` in favor <br>
> of an inlined shell snippet where the `_build_id` symbol is defined. In <br>
> keeping with the comments that specify a unique `_build_id` for each <br>
> `$(BIN)/%.tmp`, I use the first 8 characters of the md5sum of the <br>
> target, in the expected base-prefixed hexadecimal representation. <br>
> Calculating the likelihood of collisions I leave as an exercise to the <br>
> reviewer. :D<br>
<br>
The existing comment in the Makefile is not especially clear, sorry. <br>
The build ID is supposed to be collision-free across all ROMs that might <br>
ever end up installed in the same system.  It doesn't just disambiguate <br>
targets within a single build; it also disambiguates different builds.<br>
<br>
It gets used by the ROM prefix to determine when another ROM in the <br>
system contains identical code.  This happens when, for example, a <br>
multi-port NIC exposes the same iPXE ROM image for several different PCI <br>
functions, or when two identical NICs are installed in the same system. <br>
We need to know this in order to save space within the legacy BIOS <br>
option ROM area, which is extremely limited in size.<br>
<br>
Hashing the build target name is not sufficient, because that would <br>
result in a collision between the same ROM built at different times from <br>
different source trees.<br>
<br>
> The `BUILD_TIMESTAMP` assignment has been changed to allow environment <br>
> variable overriding, but it defaults to `SOURCE_DATE_EPOCH`. The source <br>
> date epoch can also be overridden; it defaults to the Unix timestamp of <br>
> the current git HEAD commit.<br>
<br>
This seems like a reasonable approach, but would need to fail gracefully <br>
when built from something that isn't a git checkout.  See the way that <br>
VERSIONS is handled for an example.<br>
<br>
Thanks,<br>
<br>
Michael<br></blockquote></div></div><div dir="auto">What if there is any local non commited changes, or config file changes, or embedded script changes. The checksum over linked solves the hash, but is it actually correct to use git as a source for BUILD_TIMESTAMP when there is local changes?</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>