<div>Forgive me if I suggest some nonsensical stuff, I confess to still not fully understand all the aspects of EFI.</div><div><br></div>So as I continue, I toyed with the idea of installing the ipxe download protocol to the loaded image device handle instead of making a brand new handle .  However, this seemed to confuse VMware's boot loader somehow, and it failed to use the ipxe download protocol correctly when I tried that.  What might VMware's boot loader be assuming that is broken when the same device handle that was used to load iPXE is used to load bootx64.efi after installing the ipxe download protocol?  <div>
<br></div><div>The reason why I was tempted is that would preserve some things currently lost on the boot device handle since the new boot device handle has only the ipxe download protocol itself right now.  For instance, being able to call device path protocol on the boot handle to extract mac address instead of relying upon argument list.  Also, the ability for something like elilo's netfs to be modified to use ipxe_download and fallback to pxebasecode with a lot of the non-transfer code left intact and not duplicated.  I suppose netfs.c could be modified to search first for the ipxe download protocol handle, and then add a call to the download protocol to get the original boot handle, but I think that could be messy compared to the simplicity of using the same handle for all the protocols.  The alternative would be to write a whole new module (my first thought) with some amount of duplicated code and such.</div>
<div><br></div><div>If I cannot really reuse the boot device handle, then I'll have to flesh out the new handle in a few ways.  Cloning the loaded image device path and either adding a way to get the 'real' boot handle or else duplicate data as needed (though the latter means potentially a lot of work and without knowing what confuses vmware's boot loader, I'd be likely to induce the same behavior anyway.<br>
<div class="gmail_quote">On Wed, Aug 10, 2011 at 3:13 PM, Geoff Lywood <span dir="ltr"><<a href="mailto:glywood@vmware.com">glywood@vmware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
----- Original Message -----<br>
<br>
> From: "Jarrod Johnson" <<a href="mailto:jarrod.b.johnson@gmail.com">jarrod.b.johnson@gmail.com</a>><br>
> To: <a href="mailto:ipxe-devel@lists.ipxe.org">ipxe-devel@lists.ipxe.org</a>, "Geoff Lywood" <<a href="mailto:glywood@vmware.com">glywood@vmware.com</a>><br>
> Sent: Wednesday, August 10, 2011 6:29:53 AM<br>
> Subject: iPXE download protocols via EFI effort<br>
<br>
> On my tree, I'm porting forward some changes from Geoff Lywood to<br>
> give iPXE the ability to install EFI protocols that chainloaded<br>
> bootloaders can use to get http and such. My goal is a sort of<br>
> 'ielilo' reminiscent of 'ipxelinux' in 'legacy' land. The biggest<br>
> question I have to date would be if the uninstall of the protocol<br>
> should happen where it does, or move to efi_init like the nic<br>
> shutdown code did when Itay modified it...<br>
<br>
> Hopefully I'll have something workable for review by end of day (need<br>
> to port over Geoff's cmdline construction which includes populating<br>
> a handle that is needed to keep elilo from hanging like it does with<br>
> ipxe today).<br>
<br>
> My next step would be an 'ipxefs' in elilo code to create a<br>
> filesystem 'protocol' over the ipxe protocol in the same way 'netfs'<br>
> constructs one over pxe base code. I briefly contemplated whether it<br>
> would be possible to implement netfs protocols and elilo would 'just<br>
> use it' without code change or even recompile, but decided that<br>
> could be a bad idea even if possible.<br>
<br>
<br>
</div></div>For the record, I did put some amount of thought into trying to make iPXE expose a protocol that is defined in the UEFI spec. The options were:<br>
<br>
EFI_LOAD_FILE_PROTOCOL: This is unsuitable because it involves loading from a device path. It is difficult to pack a URL into a device path without either defining a new device path node type, or breaking the rules around device path file name formatting (which prohibit a "//"). In either case the client would have to be modified. Additionally, at least for VMware, we wanted a smooth progress bar, and the all-or-nothing nature of this protocol meant loading several hundred megabytes over the network with no user feedback.<br>

<br>
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL: This does not work because it requires the ability to seek and such. TFTP just doesn't support the operations necessary.<br>
<br>
EFI_PXE_BASE_CODE_PROTOCOL: This one probably makes the most sense, but it's still not a good fit. This protocol is very TFTP- and MTFTP-oriented, and it would be a bit of a hack to try to slip, say, https support in under the covers. Some operations on this protocol don't make as much sense under iPXE, for example what does a "Discover" operation do, given that iPXE supports multiple NICs? And it seemed like a lot of work to expose things like the iPXE routing table, ARP cache, and cached DHCP packets up through this mechanism.<br>

<font color="#888888"><br>
- Geoff<br>
</font></blockquote></div><br></div>