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.

When we boot from a DHCP-supplied filename, we previously relied on
the fact that the current working URI is set to tftp://[next-server]/
in order to resolve the filename into a full tftp:// URI.  However,
this process will eliminate the distinction between filenames with and
without initial slashes:

 cwuri="tftp://10.0.0.1/" filename="vmlinuz"  => URI="tftp://10.0.0.1/vmlinuz"
 cwuri="tftp://10.0.0.1/" filename="/vmlinuz" => URI="tftp://10.0.0.1/vmlinuz"

This distinction is important for some TFTP servers.  We now
explicitly construct a string of the form

 "tftp://[next-server]/filename"

so that a filename with an initial slash will result in a URI
containing a double-slash, e.g.

 "tftp://10.0.0.1//vmlinuz"

The TFTP code always strips a single initial slash, and so ends up
presenting the correct path to the server.

URIs entered explicitly by users at the command line must include a
double slash if they want an initial slash presented to the TFTP
server:

  "kernel tftp://10.0.0.1/vmlinuz"  => filename="vmlinuz"
  "kernel tftp://10.0.0.1//vmlinuz" => filename="/vmlinuz"

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

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.

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

Kill off DHCP option applicators.

Add a configuration settings block for each net device.  This will
provide the parent scope for settings applicable only to that network
device (e.g. non-volatile options stored on the NIC, options obtained via
DHCP, etc.).

Expose the MAC address as a setting.

Add the notion of the settings hierarchy, complete with
register/unregister routines.

Rename set->store and get->fetch to avoid naming conflicts with get/put
as used in reference counting.

Add the concept of an abstract configuration setting, comprising a (DHCP)
tag value and an associated byte sequence.

Add the concept of a settings namespace.

Add functions for extracting string, IPv4 address, and signed and
unsigned integer values from configuration settings (analogous to
dhcp_snprintf(), dhcp_ipv4_option(), etc.).

Update functions for parsing and formatting named/typed options to work
with new settings API.

Update NVO commands and config UI to use new settings API.

show_setting() and related functions now return an "actual length" in the
style of snprintf().  This is to allow consumers to allocate buffers large
enough to hold the formatted setting.

names.

Add "dev" pointer in struct net_device to tie network interfaces back to a
hardware device.

Force natural alignment of data types in __table() macros.  This seems to
prevent gcc from taking the unilateral decision to occasionally increase
their alignment (which screws up the table packing).

the option config UI.

Introduce new {show,set,clear}_setting() that take a struct setting *
rather than a const char *.

set_setting() handles calling clear_setting() when appropriate, so that
individual setting types don't have to check for empty strings.

completely forgot I'd written ages ago.