Reading sixteen columns of hex digits can be difficult; include a "-"
character to split the output into two groups of eight columns.

Objects typically call xfer_close() as part of their response to a
close() message.  If the initiating object has already nullified the
xfer interface then this isn't a problem, but it can lead to
unexpected behaviour when the initiating object is aiming to reuse the
connection and so does not nullify the interface.

Fix by always temporarily nullifying the interface during xfer_close()
(as was already being done by xfer_vreopen() in order to work around
this specific problem).

Reported-by: infernix <infernix@infernix.net>
Tested-by: infernix <infernix@infernix.net>

These commands can be used to activate or deactivate the PXE API (on a
specifiable network interface).

This is currently of limited use, since most image formats will call
shutdown() before booting the image, meaning that the underlying net
device gets shut down during remove_devices() anyway.

setting_cmp() compares by option tag and then by name.  Empty names
will always match, which gives us a false positive.

Fix by explicitly checking for empty names.

Modified-by: Michael Brown <mcb30@etherboot.org>
Signed-off-by: Michael Brown <mcb30@etherboot.org>

Windows text editors such as Notepad tend to use CRLF line endings,
which breaks gPXE's signature detection for script images.  Since
scripts are usually very small, they end up falling back to being
detected as valid PXE executable images (since there are no signature
checks for PXE executables).  Executing text files as x86 machine code
tends not to work well.

Fix by allowing for any isspace() character to terminate the "#!gpxe"
signature, and by ensuring that CR characters get stripped during
command line parsing.

Suggested-by: Shao Miller <Shao.Miller@yrdsb.edu.on.ca>

This provides a mechanism for using arbitrarily-named variables within
gPXE, using the existing syntax for settings.

Add FILE_LICENCE declarations to almost all files that make up the
various standard builds of gPXE.

This replaces the gdbstub's polite NAK behavior with retransmission of
the current outstanding reply packet.  It solves situations where gdb
and gPXE's gdbstub get out of sync due to the lack of flow control in
the gdb protocol spec.

Signed-off-by: Michael Brown <mcb30@etherboot.org>

Now that we have xfer_vreopen() as the default .vredirect handler,
sending redirection events can become simpler.

When handling a redirection event, we need to close the existing
connection before opening the new connection.

Modified-by: Michael Brown <mcb30@etherboot.org>
Signed-off-by: Michael Brown <mcb30@etherboot.org>

Reported-by: Stefan Hajnoczi <stefanha@gmail.com>

Eliminate the potential for mismatches between table names and the
table entry data type by incorporating the data type into the
definition of the table, rather than specifying it explicitly in each
table accessor method.

Intel's C compiler (icc) chokes on the zero-length arrays that we
currently use as part of the mechanism for accessing linker table
entries.  Abstract away the zero-length arrays, to make a port to icc
easier.

Introduce macros such as for_each_table_entry() to simplify the common
case of iterating over all entries in a linker table.

Represent table names as #defined string constants rather than
unquoted literals; this avoids visual confusion between table names
and C variable or type names, and also allows us to force a
compilation error in the event of incorrect table names.

Signed-off-by: Michael Brown <mcb30@etherboot.org>

Allow for settings blocks to be created on demand.  This allows for
constructions such as

  set defaults/filename http://bootserver/bootfile
  set defaults/priority 0xff
  dhcp net0
  chain ${filename}

which will boot from the DHCP-provided filename, or from
"http://bootserver/bootfile" if the DHCP server does not provide a
filename.

(Note that "priority" gets interpreted as a signed integer, so setting
"defaults/priority" to 0xff will cause the "defaults" settings block
to have an effective priority of -1.)

Having a default script containing

  #!gpxe
  autoboot

can cause problems when entering commands to load and start a kernel
manually; the default script image will still be present when the
kernel is started and so will be treated as an initrd.  It is possible
to work around this by typing "imgfree" before any other commands, but
this is counter-intuitive.

Fix by allowing the embedded image list to be empty (in which case we
just call autoboot()), and making this the default.

Reported by alkisg@gmail.com.

When chaining COMBOOT images, the old images now get freed correctly.

Multi-level menus via COMBOOT rely on the COMBOOT program being able
to exit and invoke a new COMBOOT program (the next menu).  This works,
but rapidly (within about five iterations) runs out of space in gPXE's
internal stack, since each new image is executed in a new function
context.

Fix by allowing tail recursion between images; an image can now
specify a replacement image for itself, and image_exec() will perform
the necessary tail recursion.

This patch extends the embedded image feature to allow multiple
embedded images instead of just one.

gPXE now always boots the first embedded image on startup instead of
doing the hardcoded DHCP boot (aka autoboot).

Based heavily upon a patch by Stefan Hajnoczi <stefanha@gmail.com>.

The documentation in xfer.h and xfer.c does not say that the metadata
parameter is optional in calls such as xfer_deliver_iob_meta() and the
deliver_iob() method.  However, some code in net/ is prepared to
accept a NULL pointer, and xfer_deliver_as_iob() passes a NULL pointer
directly to the deliver_iob() method.

Fix this mess of conflicting assumptions by making everything assume
that the metadata parameter is mandatory, and fixing
xfer_deliver_as_iob() to pass in a dummy metadata structure (as is
already done in xfer_deliver_iob()).

fetchf_uristring() was failing to handle error values from
fetch_setting(), resulting in its attempting to allocate extremely
large temporary buffers on the stack (and so overrunning the stack and
locking up the machine).

Problem reported by Shao Miller <Shao.Miller@yrdsb.edu.on.ca>.

Automatically unregister any settings with the same name (and position
within the settings tree) as a newly registered settings block.

This functionality is generalised out from dhcp.c.

F8 is represented by the ANSI escape sequence "^[[19~", which is not
representable as a KEY_xxx constant using the current encoding scheme.
Adapt the encoding scheme to allow F8 to be represented, since PXE
requires that we may need to prompt the user to press F8.

Some devices take a very long time to initialise.  This can make it
difficult to visually distinguish between the error cases of failing
to start executing C code and failing to initialise a device.

Add a "gPXE initialising devices..." message.  The trailing ellipsis
indicates to the user that this may take some time, and the presence
of the message indicates to the developer that relocation etc. all
succeeded.

This brings us in to line with Linux definitions, and also simplifies
adding x86_64 support since both platforms have 2-byte shorts, 4-byte
ints and 8-byte long longs.

__cdecl is a misleading name, since it currently encapsulates both
cdecl and regparm(0) attributes.  Rename to __asmcall.

This fixes a regression introduced in commit 612f4e7:

  [settings] Avoid returning uninitialised data on error in fetch_xxx_setting()

in which the memset() was moved from fetch_string_setting() to
fetch_setting(), in order that it would be useful for non-string
setting types.  However, this neglects to take into account the fact
that fetch_string_setting() shrinks its buffer by one byte (to allow
for the NUL) before calling fetch_setting().

Restore the memset() in fetch_string_setting(), so that the
terminating NUL is guaranteed to actually be a NUL.

Some hardware vendors have been known to remove all gPXE-related
branding from ROMs that they build.  While this is not prohibited by
the GPL, it is a little impolite.

Add a facility for adding branding messages via two #defines
(PRODUCT_NAME and PRODUCT_SHORT_NAME) in config/general.h.  This
should accommodate all known OEM-mandated branding requirements.
Vendors with branding requirements that cannot be satisfied by using
PRODUCT_NAME and/or PRODUCT_SHORT_NAME should contact us so that we
can extended this facility as necessary.

Settings can be constructed using a dotted-decimal notation, to allow
for access to unnamed settings.  The default interpretation is as a
DHCP option number (with encapsulated options represented as
"<encapsulating option>.<encapsulated option>".

In several contexts (e.g. SMBIOS, Phantom CLP), it is useful to
interpret the dotted-decimal notation as referring to non-DHCP
options.  In this case, it becomes necessary for these contexts to
ignore standard DHCP options, otherwise we end up trying to, for
example, retrieve the boot filename from SMBIOS.

Allow settings blocks to specify a "tag magic".  When dotted-decimal
notation is used to construct a setting, the tag magic value of the
originating settings block will be ORed in to the tag number.
Store/fetch methods can then check for the magic number before
interpreting arbitrarily-numbered settings.

A DOS-style full path name such as "C:\Program Files\tftpboot\nbp.0"
satisfies the syntax requirements for a URI with a scheme of "C" and
an opaque portion of "\Program Files\tftpboot\nbp.0".

Add a check in parse_uri() to ignore schemes that are apparently only
a single character long; this avoids interpreting DOS-style paths in
this way, and shouldn't affect any practical URI scheme.

Callers (e.g. usr/autoboot.c) may not check the return values from
fetch_xxx_setting(), assuming that in error cases the returned setting
value will be "empty" (for some sensible value of "empty").

In particular, if the DHCP server did not specify a next-server
address, this would result in gPXE using uninitialised data for the
TFTP server IP address.

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().