[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