Hi, 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 A patch is attached that defines an interface that a bootloader may use to call back into gPXE. There are only 3 operations supported: one to start downloading a file from a URL, one to abort an in-progress download, and one to pump data from the network interface. The caller of the interface supplies callback functions that are executed as data arrives and when each download finishes. The way it is implemented, I just hooked into the xfer_* functions in gPXE, and basically exported something similar/simpler as an EFI protocol. This particular patch has not been extensively tested yet (especially the abort path), and I'm really just looking for comments and suggestions at this point. Thanks, Geoff
0001-First-cut-at-gPXE-download-protocol.patch
Description: 0001-First-cut-at-gPXE-download-protocol.patch
_______________________________________________ gPXE-devel mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe-devel
