<div dir="ltr">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.<div>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 12, 2013 at 4:20 AM, Robin Smidsrød <span dir="ltr"><<a href="mailto:robin@smidsrod.no" target="_blank">robin@smidsrod.no</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12.04.2013 00:52, Michael Brown wrote:<br>
> It's also up for debate whether or not iPXE should create a new<br>
> SNP device on top of the existing (non-iPXE-provided) SNP device and, if so,<br>
> what the device path should be.<br>
<br>
I'm not sure what these paths look like, but isn't it possible to create<br>
a new scope named iPXE, and then native drivers will go right below<br>
that, and for any SNP devices, you could have a pseudo-path element<br>
named SNP or WRAPPER or something similar, and then just copy the<br>
existing device path of the original SNP device inside there? I'm<br>
thinking about this as a simple tree, do not know if that is appropriate<br>
or not. I don't really have a lot of experience with EFI.<br>
<br>
-- Robin<br>
<br>
_______________________________________________<br>
ipxe-devel mailing list<br>
<a href="mailto:ipxe-devel@lists.ipxe.org">ipxe-devel@lists.ipxe.org</a><br>
<a href="https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel" target="_blank">https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel</a><br>
</blockquote></div><br></div>