<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">> Not available at present.  It would be sensible to remodel iPXE's SNP consumer</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">> using the mechanisms provided by efi_driver.c, thereby allowing iPXE to attach</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">> to all SNP devices in the system</span><br>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><font face="arial, sans-serif"> I decided on a scheme that works for me so I don't really care about IPXE changing behavior beyond restoring snponly.efi to work based off of loaded image handle.  The one thing I'll advocate is that if loaded image provided SNP to IPXE build without other drivers, that should always be 'net0' because that keeps things simple. Adding the capability within IPXE is beyond my current ability (I tend to break IPXE when I start trying to do something wider).  My thought on the hypothetical scenario was that snponly.c 'snpbus_probe' behavior could be extended.  First add loaded image indicated nic if indicated, then use LocateHandle to add SNP devices not matching loaded image for net1 and so on.  I don't know if it would be best to leave efi_snp out of it and just provide an alternate list of SNP pass-through devices or to merge it in.  Personally, I wasn't up to the task of the concept of merging them and if I were forced to do it, I'd probably rename 'snoponly' to 'snppassthrough' and just enumerate them independently with last_opened_snpdev poking both lists.</font></div>
<div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">For anyone else interested in what my plans are, it's to create a simple UEFI application that consumes a config file (including mac address of desired NIC), and starts IPXE up with a loaded image setup with device handle pointing at the NIC, resmbling the way PXE would look without actually doing PXE.</font></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>