[ipxe-devel] EFI_SIMPLE_FILESYSTEM_PROTOCOL commit breaks snponly.efi

[Jarrod Johnson]

> PXE 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.

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?


>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."

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.


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/20130411/4d9214b9/attachment-0001.htm>