|
From: Doug A. <amb...@am...> - 2001-06-09 20:19:33
|
Eric W. Biederman writes: | ke...@us... writes: | | > >This applies to version 5.1.0 in the src directory. It added the | > >capability to define FreeBSD kernel environment or do it via a DHCP option. | > | > Thanks, will put it in next version. | | Is there anyway we can do some kind of DHCP pass through, and just | accept extra options we are passed and pass those along? | | > >Comments on picking which option value would be helpfull. I picked 133 | > >since it was the next one after 132 which is used for the boot how to | > >flags. ISC-DHCP did something strange when I added it to the list | > >of options to request. | > | > Please voice opinions, pro or con, in this mailing list. | | Somehow if a tag is OS specific it would be nice if the OS did | the allocation itself instead of etherboot... And if not that we at The OS (really kernel) is not active at this point. These parameters given to the kernel before it starts. The only thing the kernel can access at this time is memory. No devices have been probed and this environment could effect that probe. | least would put the complexity in mknbi. I hate to see etherboot | clutered up with OS specific code, when it has size constraints. | | If we could download that code etherboot get to stay smaller. Note that it is all hidden under #define for FreeBSD so if you don't have FreeBSD defined then there is no impact. The size if the same. Well we sort-of have that type of thing. It's called the third stage loader and is PXE compliant. If EtherBoot or Nilo or whatever exposed a PXE compliant environment then this would be done. I don't see how mknbi is going to help since it at best passes static info to whatever it loads and they is no network API exposed to it to send and receive packets. Part of this patch is to be able to dynamically send parameters controled by DHCP. BTW the isc-dhcpd is getting pretty cool in the way you can classify replies and various criteria so you don't overflow the DHCP reply. For example I have parameter just for EtherBoot then parameters for the OS after device drivers are running and it can bring up the network stack and then potentially final OS configuration depending on mode of request via dhclient. This I find really powerful. The only thing missing is a fully functional UNDI PXE compliant DHCP server and a generic open source PXE boot rom. So doing PXE would let us really trim things down. I might not have been clear in my question but I was wondering if I used a previously defined option tag that had some bad side effect as opposed to just some bug that I tickled. I will try to narrow down why isc-dhcp (from the latest CVS sources had a problem) and post the results. Doug A. |
