[ipxe-devel] EFI_SIMPLE_FILESYSTEM_PROTOCOL commit breaks snponly.efi

[Jarrod Johnson]

> 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

 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.

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.


On Thu, Apr 11, 2013 at 6:52 PM, Michael Brown <mbrown at fensystems.co.uk>wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20130413/31ee4746/attachment-0001.htm>