Some libstand/bootp.c extension (written by Danny Braniss, slightly revised/modified by me) to store dhcp options into kenv variables, so the information is available to the boot loader and can be used to customize the boot process.
Some libstand/bootp.c extension (written by Danny Braniss, slightly
revised/modified by me) to store dhcp options into kenv variables,
so the information is available to the boot loader and can be used
to customize the boot process.

The change is totally unintrusive, essentially made of a single
function to be called while parsing a dhcp response, and a couple
of tables to classify options.  The values extracted from dhcp
options are stored in the kenv environment in one of these forms:

 + options whose name and type is known are saved as
        dhcp.name = value     (string, or number/ip addresses lists)

 + unknown options are assumed to be strings and saved as
        dhcp.option-NNN = "value"

 + options listed as '__INDIR' and sent on the wire as e.g.
        option unknown-252 "some.name=the actual value"
   are saved as
        some.name = "the actual value"

 + options listed as '__ILIST' and sent on the wire as e.g.
        option unknown-249 "a.b=foo bar; c.d= 123; e.f=done"
   are saved as multiple values
        a.b="foo bar"
        c.d="123"
        e.f="done"

As you can see there is quite a bit of flexibility on what can
be passed to the loader or the kernel.

For the time being the vendor-specific table is mostly disabled,
because there is no standard set of options for FreeBSD, and I don't
know all the pxe-specific vendor options.

Also, applications using libstand may live in memory-constrained
environments, so it makes sense to keep these tables as small as
possible, especially considering that one can generate arbitrary
name=value pairs using site-specific options of type __INDIR or
__ILIST (there are 4 __ILIST and 5 __INDIR in the table, numbered
246..249 and 250..254).

Actually, considering that probably 75% of the standard dhcp options
are totally useless, it might make sense to remove them as well.

Submitted by:	Danny Braniss
MFC after:	4 weeks

jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase