[gPXE-devel] [PATCH] [efi] RFC: gPXE Download Protocol
Geoff Lywood
glywood at vmware.com
Wed Jun 2 14:49:35 EDT 2010
> -----Original Message-----
> From: Michael Brown [mailto:mbrown at fensystems.co.uk]
> Sent: Wednesday, June 02, 2010 7:55 AM
> To: gpxe-devel at etherboot.org
> Cc: Geoff Lywood
> Subject: Re: [gPXE-devel] [PATCH] [efi] RFC: gPXE Download Protocol
>
> On Wednesday 02 Jun 2010 04:23:39 Geoff Lywood wrote:
> > Currently, on EFI, the image loading capabilities are fairly limited. In
> > particular, once you load up an EFI image, there is no way for that EFI
> > image to call back into gPXE in order to use the existing network
> stack.
> > So, any bootloader would need to either implement its own network
> > capabilities, or not use the network at all.
> >
> > I would like to have an interface to allow EFI bootloaders (such as
> elilo)
> > to use gPXE's network stack. In my opinion, this warrants creating a
> new
> > protocol because: - None of the standard EFI protocols support HTTP or
> > DNS, both of which are important features to me - An attempt to
> implement
> > the standard TCPv4 protocol might cause conflicts with the existing
> > firmware, because the implementation has to use global variables - The
> EFI
> > Load File Protocol is unsuitable, because it requires the underlying
> > network protocol to be able to determine the file size in advance,
> which
> > is not always possible, and it does not allow downloads to be
> interrupted
>
> Is there no EFI protocol already in existence that supports a simple
> (probably-)blocking stream model (open/read/close)?
>
> Michael
The closest thing that I know of is the EFI_FILE_PROTOCOL. The main problem that I see with it is that some protocols (multicast TFTP) don't necessarily download the file in a sequential manner.
- Geoff
More information about the gPXE-devel
mailing list