[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>
[settings] Avoid potentially large stack allocations

Avoid potentially large stack allocations in fetchf_setting() and
storef_setting().

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Remove temporary name buffer parameter from parse_setting_name()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Remove default_type parameter from parse_setting_name()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Expose parse_setting_name()

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] Add fetchf_setting_copy()

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] Eliminate call to store_named_setting() in nslookup.c

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Remove now-unused store_named_setting()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[parseopt] Allow parsed option to be modified

Parsing a setting name requires the ability to modify the text being
parsed.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[parseopt] Move parse_settings() to parseopt.c

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[parseopt] Add parse_setting()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Eliminate call to storef_named_setting() in choose_exec()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Eliminate calls to {fetch,store}f_named_setting() in NVO commands

A deliberate side effect of this commit is that the "read" command
will now preserve the type of the setting, if the setting name
contains no type information.  For example:

  iPXE> set foo:ipv4 192.168.0.1
  iPXE> read foo
  192.168.0.100
  iPXE> show foo
  foo:ipv4 = 192.168.0.100

rather than the arguably unexpected behaviour of resetting the type to
"string".

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Remove now-unused fetchf_named_setting() and storef_named_setting()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
Merge branch 'master' into osimages