<div dir="ltr"><div><span style="font-family:arial,sans-serif;font-size:13px">> PXE now requires some kind of EFI handle to which to attach the</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">> EFI_SIMPLE_FILESYSTEM_</span><span style="font-family:arial,sans-serif;font-size:13px">PROTOCOL.  It uses the handle of the SNP device </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">> returned</span><span style="font-family:arial,sans-serif;font-size:13px"> by last_opened_snpdev(), which represents the iPXE-created SNP device</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">> corresponding to the most recently opened iPXE network device.</span><br></div><div><br></div><div style>Did you have intention of addressing this limitation yourself or should someone else look into it?  For the iPXE download protocol, installing protocol against existing SNP device sufficed, do you forsee a reason why the filesystem protocol might differ in that regard?  </div>
<div><br></div><div><br></div>><span style="font-family:arial,sans-serif;font-size:13px">It's also up for debate whether or not iPXE should create a new</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">>SNP device on top of the existing (non-iPXE-provided) SNP device and, if so,</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">>what the device path should be."</span><div>
<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">I'd vote no.  For the iPXE download protocol, I had it just install prototocols on the existing SNP device (derived from loaded image protocol).  No need to create a new device just to take on new protocols (unless I'm missing something and got lucky with hooking the ipxe dl protocol that way).  The IPXE download protocol as Geoff created it did create a new device, but it was so much cleaner when I changed it to pile on the existing device in my opinion.  This was actually one nice thing (to me) about the UEFI scheme, I'm no longer subjected to widely varying IP stacks just by picking one nic versus another.  The NIC vendor provides SNP (maybe more, but I'm free to ignore it) and I can more cleanly apply something like IPXE without the cooperation of the NIC vendor is one way or another.</span></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 11, 2013 at 6:52 PM, Michael Brown <span dir="ltr"><<a href="mailto:mbrown@fensystems.co.uk" target="_blank">mbrown@fensystems.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thursday 11 Apr 2013 14:26:27 Jarrod Johnson wrote:<br>
> I'm presuming either something got skipped and snponly 'net0' device should<br>
> have been subjected to magic from efi_pci.c or else that efi_snp.c adds a<br>
> case to recognize the particular 'net0' that is currently constructed as-is<br>
> (I'm guessing it must grab it based on loaded image protocol, but I haven't<br>
> looked that hard).<br>
<br>
</div>iPXE now requires some kind of EFI handle to which to attach the<br>
EFI_SIMPLE_FILESYSTEM_PROTOCOL.  It uses the handle of the SNP device returned<br>
by last_opened_snpdev(), which represents the iPXE-created SNP device<br>
corresponding to the most recently opened iPXE network device.<br>
<br>
In the case of snponly, iPXE does not create a new SNP device.  Hence the<br>
problem.<br>
<div class="im"><br>
> As an aside, what's the correct efi binary name to build/approach to have<br>
> an ipxe binary that can use any of the snp devices available, not just the<br>
> snp device as discovered through loaded image protocol?  The use case being<br>
> arbitrary SNP drivers and ipxe starting from a non-network context such as<br>
> vfat partition on local flash.<br>
<br>
</div>Not available at present.  It would be sensible to remodel iPXE's SNP consumer<br>
using the mechanisms provided by efi_driver.c, thereby allowing iPXE to attach<br>
to all SNP devices in the system.  Some care would need to be taken to avoid<br>
recursion.  It's also up for debate whether or not iPXE should create a new<br>
SNP device on top of the existing (non-iPXE-provided) SNP device and, if so,<br>
what the device path should be.<br>
<span class="HOEnZb"><font color="#888888"><br>
Michael<br>
</font></span></blockquote></div><br></div>