[ipxe-devel] EFI_SIMPLE_FILESYSTEM_PROTOCOL commit breaks snponly.efi

[Jarrod Johnson]

Ok, so I have a patch.  It is a terrible patch, but it demonstrates roughly
how to restore snponly capability.  My patch is horrible because it
explicitly breaks the efforts to do efipci, but I thought it would be best
to have code to backup how I suggest it be done.  In short, just
efi_image.c should change.

Basically, efi_image.c should go ahead and try the last_opened_snpdev. If
that works, put its devpath and handle into some variables.  If that should
not work, do the same thing snpbus_probe does (check loaded image for SNP
protocol).  If loaded_image has an SNP, then store the relevant devpath and
handle into the aforementioned variables to add the relevant slick IPXE
protocols to it and pass it through (slick ones being the download and
exceptionally cool filesystem one, which I confirmed will work snponly with
this strategy).  Ignore the irrevelant ones (HII, Loadfile, etc) which only
have sane meaning when part of efirom or efidrv.

This patch commits the sin of skipping the check and bludgeoning things the
snponly way.   The part about switching between snpdev and snponly and
still failing is straightforward, but I didn't take the time (will take the
time if no one else does).  I'dd also make the bludgeoning of the
DeviceHandle optional (though I don't claim to quite understand why I must
do it).

I put the patch into xCAT's repository under a branch for posterity:
https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/19447d9c39e06c3d5aabd198736cd23d8e40c870


On Thu, Apr 11, 2013 at 11:40 PM, Jarrod Johnson <jarrod.b.johnson at gmail.com
> wrote:

> > Some care would need to be taken to avoid
> > recursion.
>
> On this, I think the correct answer would be for the IPXE protocols, check
> and uninstall if already there prior to installing new instance of the
> protocol. No new device handle needed, just replace the relevant protocols
> and leave any ohter protocols alone, therefore no risk of too much
> recursion (yes, snponly.efi would rip out bits of ipxe when chained from an
> already ipxe capable device, but that would be expected behavior as
> presumably the chainloaded instance is customized and/or better tested for
> that environment compared to flashed instance...)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20130412/34aca5db/attachment.htm>