[ipxe-devel] EFI_SIMPLE_FILESYSTEM_PROTOCOL commit breaks snponly.efi

[Michael Brown]

On Thursday 11 Apr 2013 14:26:27 Jarrod Johnson wrote:
> I'm presuming either something got skipped and snponly 'net0' device should
> have been subjected to magic from efi_pci.c or else that efi_snp.c adds a
> case to recognize the particular 'net0' that is currently constructed as-is
> (I'm guessing it must grab it based on loaded image protocol, but I haven't
> looked that hard).

iPXE now requires some kind of EFI handle to which to attach the 
EFI_SIMPLE_FILESYSTEM_PROTOCOL.  It uses the handle of the SNP device returned 
by last_opened_snpdev(), which represents the iPXE-created SNP device 
corresponding to the most recently opened iPXE network device.

In the case of snponly, iPXE does not create a new SNP device.  Hence the 
problem.

> As an aside, what's the correct efi binary name to build/approach to have
> an ipxe binary that can use any of the snp devices available, not just the
> snp device as discovered through loaded image protocol?  The use case being
> arbitrary SNP drivers and ipxe starting from a non-network context such as
> vfat partition on local flash.

Not available at present.  It would be sensible to remodel iPXE's SNP consumer 
using the mechanisms provided by efi_driver.c, thereby allowing iPXE to attach 
to all SNP devices in the system.  Some care would need to be taken to avoid 
recursion.  It's also up for debate whether or not iPXE should create a new 
SNP device on top of the existing (non-iPXE-provided) SNP device and, if so, 
what the device path should be.

Michael