We have EFI APIs for CPU I/O, PCI I/O, timers, console I/O, user
access and user memory allocation.

EFI executables are created using the vanilla GNU toolchain, with the
EXE header handcrafted in assembly and relocations generated by a
custom efilink utility.

monojob_wait() was holding a reference to the completed job, meaning that
various objects would not be freed until the next job was plugged in to
the monojob interface.

The EFI timer runs at one tick per second, so using ">" rather than ">="
results in a two-second gap between dots.

We now have two implementations for the timer API: one using the
time-of-day counter at 40:70 and one using RDTSC.  Both make use of
timer2_udelay().

This allows settings to be expanded in a way that is safe to include
within a URI string, such as

  kernel http://10.0.0.1/boot.php?mf=${manufacturer:uristring}

where the ${manufacturer} setting may contain characters that are not
permitted (or have reserved purposes) within a URI.

Since whitespace characters will be URI-encoded (e.g. "%20" for a
space character), this also works around the problem that spaces
within an expanded setting would cause the shell to split command-line
arguments incorrectly.

fetch_string_setting() was subtracting one from the length of the
to-be-NUL-terminated buffer in order to obtain the length of the
unterminated buffer to be passed to fetch_setting().  This works
extremely well unless the length of the to-be-NUL-terminated buffer is
zero, at which point we end up giving fetch_setting() a buffer of
length -1UL, thereby inviting it to overwrite as much memory as it
wants...

Allow initiator to verify target authentication using CHAP.

Allow settings to be expanded in arbitrary commands, such as

  kernel http://10.0.0.1/boot.php?uuid=${uuid}

Also add the "echo" command, as being the easiest way to test this
features.

Print one dot per second while waiting in monojob.c (e.g. for DHCP,
for file downloads, etc.), to inform user that the system has not
locked up.

Patch contributed by Andrew Schran <aschran@google.com>, minor
modification by me.

Add yet another ugly hack to iscsiboot.c, this time to allow the user to
inhibit the shutdown/removal of the iSCSI INT13 device (and the network
devices, since they are required for the iSCSI device to function).

On the plus side, the fact that shutdown() now takes flags to
differentiate between shutdown-for-exit and shutdown-for-boot means that
another ugly hack (to allow returning via the PXE stack on BIOSes that
have broken INT 18 calls) will be easier.

I feel dirty.

Clearing the LOADED flag actually prevents users from doing clever things
such as loading an image, then loading a patch image, then executing the
first image.  (image_exec() checks for IMAGE_LOADED, so this sequence of
operations will fail if the LOADED flag gets cleared.)

This reverts commit 14c080020f.

Loading an image may overwrite part or all of any previously-loaded
images, so we should clear the LOADED flag for all images prior to
attempting to load a new image.

This commit implements GDB over UDP.  Using UDP is more complex than
serial and has required some restructuring.

The GDB stub is now built using one or both of GDBSERIAL and GDBUDP
config.h options.

To enter the debugger, execute the gPXE shell command:
gdbstub <transport> [<options>...]

Where <transport> is "serial" or "udp".  For "udp", the name of a
configured network device is required:
gdbstub udp net0

The GDB stub listens on UDP port 43770 by default.

This commit also includes a test to ensure that single stepping works,
since continue, kill, detach, and single step all share code.

Avoid calling cpu_nap() until after we have determined that there is
no input ready to read.  This avoids delaying for one timer interrupt
(~50ms) in the case of

  if ( iskey() )
     char = getkey()

which happens to be present in monojob.c, which is where we spend most
of our time looping (e.g. during any download).

This should eliminate the irritating tendency of gPXE to lose
keypresses.

Discovered on a Dell system where the serial port seems to send in a
constant stream of 0xff characters; this wouldn't be a problem in
itself except that each one triggers the 50ms delay (as mentioned
above), which really kills performance.

Delete ELF as a generic image type.  The method for invoking an
ELF-based image (as well as any tables that must be set up to allow it
to boot) will always depend on the specific architecture.  core/elf.c
now only provides the elf_load() function, to avoid duplicating
functionality between ELF-based image types.

Add arch/i386/image/elfboot.c, to handle the generic case of 32-bit
x86 ELF images.  We don't currently set up any multiboot tables, ELF
notes, etc.  This seems to be sufficient for loading kernels generated
using both wraplinux and coreboot's mkelfImage.

Note that while Etherboot 5.4 allowed ELF images to return, we don't.
There is no callback mechanism for the loaded image to shut down gPXE,
which means that we have to shut down before invoking the image.  This
means that we lose device state, protection against being trampled on,
etc.  It is not safe to continue afterwards.

See http://etherboot.org/wiki/dev/gdbstub for documentation.

The GDBSYM config.h option was an attempt at QEMU GDB debugging.  I have
removed the code since it is unused and may confuse people wanting to
use the GDB stub.

Various specification documents disagree about the byte ordering of
UUIDs.  However, SMBIOS seems to use the standard in which everything is
in network-endian order.

This doesn't affect anything sent on the wire; only what gets printed on
the screen when the "uuid" variable is displayed.

In particular, expose the system UUID as a setting ("smbios/uuid").

read_user() assumes that zero-length buffers don't exist, and optimises
around this.

Allow for settings to be described by something other than a DHCP option
tag if desirable.  Currently used only for the MAC address setting.

Separate out fake DHCP packet creation code from dhcp.c to fakedhcp.c.

Remove notion of settings from dhcppkt.c.

Rationalise dhcp.c to use settings API only for final registration of the
DHCP options, rather than using {store,fetch}_setting throughout.

It's probably easier to have a named setting for next-server, rather
than to explain to people why they need to pretend it is option 175.3.

IPv4 may not always be dragged into the link, so add a specific
configuration option for it.

Convert DHCP option applicators in dns.c and iscsi.c to settings
applicators.

Kill off DHCP option applicators.