Allow for equivalent IPv4 and IPv6 settings (which requires equivalent
settings to be adjacent within the settings list).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Allow for multiple definitions of each predefined setting
Allow for multiple setting definitions with the same name but
different scopes and tags. For example, allow for a "filename"
setting with default scope and tag value 67 (for DHCPv4) and a
corresponding "filename" setting with IPv6 scope and tag value 59 (for
DHCPv6).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Allow for IPv6 setting types in non-IPv6 builds
Allow for the existence of references to IPv6 setting types without
dragging in the whole IPv6 stack, by placing the definition of
setting_type_ipv6 in core/settings.c and providing weak stub methods
for parse_ipv6_setting() and format_ipv6_setting().
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Explicitly separate the concept of a completed fetched setting
The fetch_setting() family of functions may currently modify the
definition of the specified setting (e.g. to add missing type
information). Clean up this interface by requiring callers to provide
an explicit buffer to contain the completed definition of the fetched
setting, if required.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[console] Allow '?' as an intermediate byte in ANSI escape sequences
The ANSI escape sequences to show and hide the cursor take the form
"<ESC>[?25h" and "<ESC>[?25l" respectively. iPXE currently treats the
'?' character as the final byte. Fix by explicitly treating '?' as an
intermediate byte.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[main] Defer "initialising devices" message until initialising devices
Allow the "initialising devices" message to show up on consoles which
require initialisation, by deferring it until after initialise() has
completed.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[monojob] Report ongoing job status as overall return status on timeout
If a job times out then use the most recent ongoing error status
reported via job_progress() (if available) as the overall return
status.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[job] Allow job_progress() to return an ongoing job status code, if known
Some background jobs have a meaningful ongoing status code (e.g. the
current link status for a job waiting for a network link to come up).
Allow this to be exposed via the job_progress() method.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[interface] Default to calling intf_restart() in response to intf_close()
If an object interface does not provide an intf_close() method, then
default to calling intf_restart(). This allows static objects to
safely ignore intf_close(), without needing to add code solely to
ensure that the interface gets unplugged.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Parsing a timeout value (specified in milliseconds) into an internal
timeout value measured in timer ticks is a common operation. Provide
a parse_timeout() value to carry out this conversion automatically.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add generic pinger mechanism (analogous to the generic downloader
mechanism) which opens a ping socket, transmits ping requests, and
passes information about ping replies to a callback function.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow for configurable provision of built-in settings by placing them
in a linker table rather than an array.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
HTTP POST requires the ability to associate a parameter list with a
URI. There is no standardised syntax for this. Use a non-standard
URI syntax to incorporate the specification of a parameter list within
a URI:
URI = [ absoluteURI | relativeURI ]
[ "#" fragment ] [ "##params" [ "=" paramsName ] ]
e.g.
http://boot.ipxe.org/demo/boot.php##paramshttp://boot.ipxe.org/demo/boot.php##params=mylist
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Expose memory map via settings mechanism
Allow memory map entries to be read using the syntax
${memmap/<region>.<properties>.<scale>}
where <region> is the index of the memory region, <properties> is a
bitmask where bit 0 represents the start address and bit 1 represents
the length (allowing the end address to be encoded by having both bits
0 and 1 set), and <scale> is the number of bits by which to shift the
result.
This allows for several values of interest to be encoded. For
example:
${memmap/<region>.1.0:hexraw} # 64-bit start address of <region>
${memmap/<region>.2.0:hexraw} # 64-bit length of <region>, in bytes
${memmap/<region>.3.0:hexraw} # 64-bit end address of <region>
${memmap/<region>.2.10:int32} # Length of <region>, in kB
${memmap/<region>.2.20:int32} # Length of <region>, in MB
The numeric encoding is slightly more sophisticated than described
here, allowing a single encoding to cover multiple regions. (See the
source code for details.) The primary use case for this feature is to
provide the total system memory size (in MB) via the "memsize"
predefined setting.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Allow numeric_setting_value() to handle long setting values
Allow numeric_setting_value() to handle e.g. the byte sequence
00:00:00:00:12:34:56:78
by returning -ERANGE only if the value actually overflows the return
type.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Eliminate call to fetchf_named_setting() in expand_settings()
Use parse_setting_name() and fetchf_setting_copy() in
expand_settings(), to eliminate the call to fetchf_named_setting().
This change also eliminates the potentially large stack-allocated
buffer in expand_settings().
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Change "not-found" semantics of fetch_setting_copy()
fetch_settings_copy() currently returns success and a NULL data
pointer to indicate a non-existent setting. This is intended to allow
the caller to differentiate between a non-existent setting and an
error in allocating memory for the copy of the setting.
The underlying settings blocks' fetch() methods provide no way to
perform an existence check separate from an attempt to fetch the
setting. A "non-existent setting" therefore means simply a setting
for which an error was encountered when attempting to fetch from every
settings block within the subtree.
Since any underlying error within a settings block (e.g. a GuestRPC
failure when attempting to retrieve a VMware GuestInfo setting) will
produce the effect of a "non-existent setting", it seems somewhat
meaningless to give special treatment to memory allocation errors
within fetch_setting_copy().
Remove the special treatment and simplify the semantics of
fetch_setting_copy() by directly passing through any underlying error
(including non-existence) encountered while fetching the setting.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Clarify usage of the term "named setting"
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>
[base16] Ensure base16_encode() always terminates its result string
base16_encode() will fail to generate a terminating NUL if the length
of the raw data is zero, since the loop calling sprintf() will never
execute.
Fix by explicitly terminating the result with a NUL.
Reported-by: Marin Hannache <git@mareo.fr>
Debugged-by: Marin Hannache <git@mareo.fr>
Tested-by: Marin Hannache <git@mareo.fr>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown