[ipxe-devel] Wrapped iPXE EFI SNP device paths (was: Re: EFI_SIMPLE_FILESYSTEM_PROTOCOL commit breaks snponly.efi)

[Jarrod Johnson]

I think my patch to revert shows approximately the best strategy when
dealing with existing SNP device.  Do not create a new device, just install
the ipxe protocols relevant to enhancing image load onto the existing one
and ignore the lower level ones that really only make sense when IPXE is
providing the entirety of a devices firmware implementation.  It was
helpful that the distinction between the two sorts of protocols already was
split nicely between efi_snp and efi_image.  Simple and straightforward.



On Fri, Apr 12, 2013 at 4:20 AM, Robin Smidsrød <robin at smidsrod.no> wrote:

> On 12.04.2013 00:52, Michael Brown wrote:
> > 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'm not sure what these paths look like, but isn't it possible to create
> a new scope named iPXE, and then native drivers will go right below
> that, and for any SNP devices, you could have a pseudo-path element
> named SNP or WRAPPER or something similar, and then just copy the
> existing device path of the original SNP device inside there? I'm
> thinking about this as a simple tree, do not know if that is appropriate
> or not. I don't really have a lot of experience with EFI.
>
> -- Robin
>
> _______________________________________________
> ipxe-devel mailing list
> ipxe-devel at lists.ipxe.org
> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20130413/fccec88f/attachment.htm>