O.k. Etherboot is now passing it's current architecture, in dhcp options.
I am currently using encapsulated option #177.
What we are doing and what we wish to accomplish with the DHCP options
needs to documented clearly, and scrubbed a little bit. For the moment
I don't want to break the code so I have not done anything radical.
Currently etherboot does not interpret any encapsulated options
(except in the case of FreeBSD).
When using encapsulated options we are not checking for a magic signature.
The code that uses the non-standard DHCP options is now in mknbi,
and it doesn't use encapsulated options.
For a reference case PXE uses vendor encapsulated options, which
makes it likely we won't run into problems if we use it as well. Especially
if we require a signature option immediate inside of the vendor encapsulated
options.
In addition we do expect a vendor encapsulated option with REQUIRE_VCI_ETHERBOOT.
So placing more options in the vendor encapsulated options field sounds
quite reasonable to me.
With respect to transmitting options I am less certain on how that
should be handled. But my gut impression says vendor encapsulated
options is the way to go. But it has been suggested that dhcpv3
cannot parse those options. I will at least want to verify that
before I go any further.
Cleaning all of this up should also reduce our code size as well,
which is probably the good etherboot reason for doing it.
With respect to conflicts in the vendor encapsulated options field,
if we require VCI etherboot to be present before looking at any
of the other tags we should be safe in assuming the tags are etherboot
safe. And the tag can be sent a second time for strange clients
that also want to use VCI etherboot.
Eric
|