<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 2, 2020 at 6:40 PM Michael Brown <<a href="mailto:mcb30@ipxe.org">mcb30@ipxe.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 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></blockquote><div><br></div><div>Okay, understood. If I take your meaning correctly, then it would be enough to hash a concatenation of the `$(SOURCE_DATE_EPOCH)` with the target name. The relevant shell expression would become...</div><div><br></div><div>    echo $(SOURCE_DATE_EPOCH) $@ | md5sum | head -c8<br></div><div><br></div><div>Would that get it done? Or did I interpret your mention of "different times" too literally?</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">
> 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.</blockquote><div><br></div><div>Can do. Look for it in my next patch.</div><div><br></div><div><br></div></div></div>