I'd note in your commit message that several files were pulled in verbatim from EDK2 and they contain pointers to a URL for the license. And that we're committing them verbatim because it's the vendor's preferred method of communicating the license, even though it's a bit at odds with normal project practice.

I'd use C style comments here, and below. This file is a FreeBSD file.

this seems misplaced.... why is it here? Others are in stand.h

checked too late

error handling above seems thin.

host not checked.
Also, consider using strdup instead.

assumes c is non-null.

Is there some way to time-bound this wait? And the one below?

wouldn't it be safer to set this BEFORE you call CreateEvent? This pattern is used several times and I'll just comment once.

All these other fsops are defined in stand.h

stand.h looks to be the right place for extern struct fs_ops efihttp_fsops, but this seems to be the right place for the &efihttp_fsops?

Yes, I'll add a call to BS->Stall() and wait 10 seconds.

The done? Or calling __compiler_membar()?
I'll move the done up before the CreateEvent.

I'd cap the the upper bound to be some variable that can be set.

shouldn't we set done to false, forcing it to be false before we create a task/thread that might change it?

Correct on both accounts.

Given that the other network code doesn't do that, and was instead taking over an hour to timeout, I think simply capping it at 10 seconds is sufficient for now.

Yes, I agree - I'll fix it.

Some reasonable upper limit is needed for how long the network waits. Where else do we wait an unbounded amount of time?

We used to take a really long time for send/recv in stand/libsa/net.c to timeout. From https://svnweb.freebsd.org/base/head/stand/libsa/net.c?revision=342282&view=markup :P

Wait a maximum of 300 seconds for network send/recv in libsa

The reason for this change is that currently, a send/recv takes many hours to time out.
This is suboptimal in the bootloader because it means for example that NFS will take hours to fail before allowing subsequent access methods such as gzip to be tried.

Setting MAXWAIT to 300 seconds (5 minutes) still allows slow connections of 1Mb to be used to download a 30MB kernel file.

no error handling here...