>>>The key is that the handle _itself_ is the proper link between the EFI_PXE_BASE_CODE_PROTOCOL and EFI_UDP4_SERVICE_BINDING_PROTOCOL. _IT_ is the piece that must be stored and reused. I found this thanks to a Google search "EFI_PXE_BASE_CODE_PROTOCOL EFI_MANAGED_NETWORK_PROTOCOL" and http://sourceforge.net/p/edk2/mailman/message/31604654/ where Laszlo Ersek showed the output of a command that made things "click" in my mind to understand the relationship. <<< This is somehow surprising but dumping handles at the shell I've verified that in my VMware UEFI client the Pxebc protocol and all the Service binding protocols (including UDPv4Sb) corresponding to one particular NIC (on a 2 NIC client) share "the same" handle #. I wonder if we can really rely on this. I'm trying to find in the UEFI 2_5.pdf and UEFI_Driver_Writer_Guide_V1.0.1_120308.pdf something supporting this fact but so far I cannot find anything... >>> Now, as for the case of multiple potentially valid handles with EFI_PXE_BASE_CODE_PROTOCOL, this would completely invalidate the idea of a search.? If there are multiple handles with EFI_PXE_BASE_CODE_PROTOCOL data that could be usable, it's impossible to perform a valid search.? If an implementation does in fact do this, we must find a completely different way to query the EFI firmware for the proper handle. <<< i.e. a PC with two NICs connected to 2 Networks with PXE servers on it. Probably we should think about this later. I'm more concern about the validity of the previous handle assumption.>>>Consider the case of PXE booting NIC-1 then the NBP decides to abort and return control to the EFI firmware (presuming this is possible; I haven't tested LOCALBOOT yet) then boot NIC-2 and load Syslinux.? How do we know which is valid?? Presume NIC-1 had a filename "syslinux.efi" while NIC-2 "bootx64.efi".? Now consider if NIC-3 came first in the boot order. <<< Yes I know what you mean; "I think" the handle of the running image (our code) has a "path" telling us where was laded from. That would solve this thing. Best, Patrick
On Thu, Jun 25, 2015 at 11:54 AM, Patrick Masotta <masottaus at yahoo.com> wrote:> Yes I know what you mean; > "I think" the handle of the running image (our code) has a "path" telling us where > was laded from. That would solve this thing.I just found we already found the handle before in a more reliable manner and we already found it in the beginning of execution in efi_main(). -- -Gene
On Thu, Jun 25, 2015 at 7:28 PM, Gene Cumm <gene.cumm at gmail.com> wrote:> On Thu, Jun 25, 2015 at 11:54 AM, Patrick Masotta <masottaus at yahoo.com> wrote: > >> Yes I know what you mean; >> "I think" the handle of the running image (our code) has a "path" telling us where >> was laded from. That would solve this thing. > > I just found we already found the handle before in a more reliable > manner and we already found it in the beginning of execution in > efi_main(). > > -- > -GeneCommit 23b2707 should resolve this. Please let me know if you need test binaries -- -Gene