|
From: <ebi...@ln...> - 2002-12-13 01:10:00
|
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 |
