There are currently two conflicting usages of the term "named setting"
within iPXE: one refers to predefined settings (such as show up in the
"config" UI), the other refers to settings identified by a name (such
as "net0.dhcp/ip").
Split these usages into the term "predefined setting" and "named
setting" to avoid ambiguity.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add a facility for settings blocks to act as symbolic links to other
settings blocks, and reimplement the "netX" virtual settings block
using this facility.
The primary advantage of this approach is that unscoped settings such
as ${mac} and ${filename} will now reflect the settings obtained from
the most recently opened network device: in most cases, this will mean
the settings obtained from the most recent DHCP attempt. This should
improve conformance to the principle of least astonishment.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow network device's "busloc" setting to be formatted as a PCI
bus:dev.fn address using e.g. ${net0/busloc:busdevfn}.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Use hex_decode() to parse "hex" and "hexhyp" settings. Note that this
parser is stricter than the old parser; it now requires exactly two
hex digits for each byte. (The old parser was based upon strtoul()
and so would allow leading whitespace and a leading plus or minus
sign.)
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Create an explicit concept of "settings scope" and eliminate the magic
values used for numerical setting tags.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Expose the build architecture (e.g. "i386" or "x86_64") via
${buildarch} and the firmware platform (e.g. "pcbios" or "efi") via
${platform}. These settings directly expose the ARCH and PLATFORM
variables from the Makefile.
Note that the build architecture reflects the architecture for which
iPXE was compiled, not the architecture on which iPXE is currently
running. The "cpuid" command can be used to detect a 64-bit system at
runtime.
Requested-by: James A. Peltier <jpeltier@sfu.ca>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When fetching a named setting using a name that does not explicitly
specify a type, default to using the type stored when the setting was
created, rather than always defaulting to "string". This allows the
behaviour of user-defined settings to match the behaviour of
predefined settings (which have a sensible default type).
For example:
set server:ipv4 192.168.0.1
echo ${server}
will now print "192.168.0.1", rather than trying to print out the raw
IPv4 address bytes as a string.
The downside of this change is that existing tricks for printing
special characters within scripts may require (backwards-compatible)
modification. For example, the "clear screen" sequence:
set esc:hex 1b
set cls ${esc}[2J
echo ${cls}
will now have to become
set esc:hex 1b
set cls ${esc:string}[2J # Must now explicitly specify ":string"
echo ${cls}
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow scripts to report errors in more detail by exposing the most
recent error via the ${errno} setting. For example:
chain ${filename} || goto failed
...
:failed
imgfree http://192.168.0.1/ipxe_error.php?error=${errno}
Note that ${errno} is valid only immediately after executing a failed
command.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow TFTP to be configured out by moving the next-server setting
definition (which is used by autoboot.c) from tftp.c to settings.c.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Refactor setting type handlers to parse and format values, rather than
storing and fetching formatted values.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Improve the appearance of the "config" user interface by ensuring that
settings appear in some kind of logical order.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 5fbd020 ("[settings] Display canonical setting name in output
of "show" command") introduced a regression causing all setting
expansions (e.g. "${net0/mac}") to expand to an empty string.
Fix by returning the formatted value length from
fetchf_named_setting(), as expected by the caller.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Enable the "show" command to display the full, canonicalised name of
the fetched setting. For example:
iPXE> show mac
net0/mac:hex = 52:54:00:12:34:56
iPXE> dhcp && show ip
DHCP (net0 52:54:00:12:34:56)... ok
net0.dhcp/ip:ipv4 = 10.0.0.168
iPXE> show net0/6
net0.dhcp/dns:ipv4 = 10.0.0.6
Inspired-by: Glenn Brown <glenn@myri.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Expose settings_name(), shrink the unnecessarily large static buffer,
properly name root settings block, and simplify.
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Expose a function setting_applies() to allow a caller to determine
whether or not a particular setting is applicable to a particular
settings block.
Restrict DHCP-backed settings blocks to accepting only DHCP-based
settings.
Restrict network device settings blocks to accepting only DHCP-based
settings and network device-specific settings such as "mac".
Inspired-by: Glenn Brown <glenn@myri.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Most callers of functions in the fetch_setting() family treat any
errors as meaning "non-existent setting". In the case of
fetch_string_setting_copy(), an existent setting can still result in
an error due to memory allocation failure.
Allow the caller to distinguish between a non-existent setting and an
error in allocating memory for the copy, by returning success (and a
NULL buffer pointer) for a non-existent setting.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
For consistency with other functions in the fetch_setting() family,
ensure that fetch_string_setting_copy() always initialises the pointer
to the fetched setting even if fetching fails.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Pass the settings block name as a parameter to register_settings(),
rather than defining it with settings_init() (and then possibly
changing it by directly manipulating settings->name).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Provide a "hexhyp" setting type, which functions identically to the
"hex" setting type except that it uses a hyphen instead of a colon as
the byte delimiter.
For example, if ${mac} expands to "52:54:00:12:34:56", then
${mac:hexhyp} will expand to "52-54-00-12-34-56".
Originally-implemented-by: Jarrod Johnson <jarrod.b.johnson@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The DHCP settings registered as a child of the netdevice settings are
not unregistered anywhere. This prevents the netdevice from being
freed on shutdown.
Fix by automatically unregistering any child settings when the parent
settings are unregistered.
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Access to the gpxe.org and etherboot.org domains and associated
resources has been revoked by the registrant of the domain. Work
around this problem by renaming project from gPXE to iPXE, and
updating URLs to match.
Also update README, LOG and COPYRIGHTS to remove obsolete information.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The NFS protocol code came from legacy Etherboot and was never updated
to work as a gPXE protocol. There has been no demand for this protocol,
so this patch removes it.
I have an unfinished NFSv3 over TCP implementation for gPXE that can be
used as the base for new work, should we want to resurrect this
protocol.
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>
Currently, handling of URI escapes is ad-hoc; escaped strings are
stored as-is in the URI structure, and it is up to the individual
protocol to unescape as necessary. This is error-prone and expensive
in terms of code size. Modify this behavior by unescaping in
parse_uri() and escaping in unparse_uri() those fields that typically
handle URI escapes (hostname, user, password, path, query, fragment),
and allowing unparse_uri() to accept a subset of fields to print so
it can be easily used to generate e.g. the escaped HTTP path?query
request.
Signed-off-by: Joshua Oreman <oremanj@rwcr.net>
Signed-off-by: Marty Connor <mdc@etherboot.org>
A script loaded via autoboot may want to get some of the settings (MAC
address, IP address, et cetera) for the interface via which it was
loaded, in order to pass them to the operating system. Previously such
a script had no way to determine what to put in the X of ${netX/foo}.
Solve this problem by transparently forwarding accesses to the real
settings associated with the most recently opened network device,
so scripts in this situation can say literally ${netX/foo} and get
the foo setting they want.
Signed-off-by: Marty Connor <mdc@etherboot.org>
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>
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.
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.)
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>.
Michael Brown