[autoboot] Retain initial-slash (if present) when constructing TFTP URIs
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"
[Settings] Remove assumption that all settings have DHCP tag values
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.
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.
[Settings] Start revamping the configuration settings API.
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.
Add "name" field to struct device to allow human-readable hardware device
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).
Move {show,set,clear}_setting() to {show,set,clear}_named_setting().
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.
Michael Brown