On Fri, Mar 18, 2016 at 11:05:25AM +0000, Michael Brown wrote:
> On 17/03/16 23:11, Todd Stansell wrote:
> >Well, it turns out that for the dhcpack bits, it's less complicated than we
> >originally thought. We turned to hacking on the ipxe code to try to see
> >what's actually required to get this to work and now have a working patch.
> >It
> >might not be ideal, but it does seem to work. I'm including it as an
> >attachment here. We took the option of storing the dhcpack packet inside a
> >setting and then also requiring another setting to actually use it. That
> >way
> >an ipxe config could optionally have the multiboot code fire to embed the
> >dhcpack only when it knows it's a solaris network boot that's required.
> >
> >Is there any chance some form of this patch could be implemented in ipxe
> >so we
> >don't have to run custom ipxe code?
>
> What are the requirements that Solaris has here?
>
> It looks as though Solaris expects to see a DHCPACK packet pointed to by
> the mbinfo's {drives_addr,drives_len} fields.
Correct. Since doing this is not a multiboot standard, the pxegrub code also
makes sure the MBI_FLAG_DRIVES flag is unset. Solaris also requires the
MBI_FLAG_BOOTDEV flag is set with mbinfo.boot_device = 0x20ffffff.
> If so, then strip out everything relating to the solaris_dhcp_cache
> blob, and use create_fakedhcpack() to construct the DHCPACK. This will
> create a DHCPACK containing the settings as actually used by iPXE for
> the relevant network device. This is what our PXE API uses to provide
> the DHCPACK for PXENV_GET_CACHED_INFO; see pxe_fake_cached_dhcpinfo() in
> arch/x86/interface/pxe/pxe_preboot.c.
>
> One easy solution would be to simply call pxe_fake_cached_info() before
> starting a Multiboot image to construct the standard set of DHCP packets
> as used by the PXE API, and then to pass the address of the DHCPACK via
> mbinfo. This would have a negligible code size impact, which is good.
>
> The downside is that the buffers used for the PXE API are exactly the
> size of a BOOTPLAYER_t structure (as defined by the PXE spec), and this
> buffer may not be large enough to hold a DHCP packet containing large
> number of options. (See the comment in pxe_preboot.c for details.)
>
> If we care about being able to pass a full-sized DHCP packet to Solaris,
> then it might be better to use create_fakedhcpack() directly. This
> could potentially share the same buffer space in .bss16 as the three
> BOOTPLAYER_t packets used by pxe_preboot.c, since booting a Multiboot
> kernel is mutually exclusive with booting a PXE NBP.
Our patch was simply using a BOOTPLAYER_t structure, so we don't seem to need
a full-sized DHCP packet. All of the complex solaris options are passed as
kernel arguments. So, going with the simple solution is probably fine.
> >We're also still working on the idea of uncompressing the image on the fly
> >so
> >we don't have such a huge image to transfer over the network, but this is a
> >good first step. Any thoughts on this topic would be greatly appreciated.
>
> We already have support for the raw decompression algorithm in
> crypto/deflate.c, which we use for PNG image support. We don't
> currently have support for the gzip headers/footers.
Solaris uses gzip to compress their images, so it would need to support that.
> There are (at least) two ways that this could usefully be implemented.
> One would be to add support for a compressed HTTP content/transfer
> encoding. The HTTP core does now provide an infrastructure to allow
> this sort of feature to be plugged in as a link-time option.
>
> Other options would be to perform the decompression on demand (e.g. via
> a "gunzip" command), or to automatically perform decompression for
> Multiboot images since that's the way that some other bootloaders
> already behave.
It would be great if it automatically decompressed it like other bootloaders,
but I suppose I'm okay with any solution that works. :)
Thanks!
Todd
_______________________________________________
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
