|
From: Doug A. <amb...@am...> - 2001-06-10 03:54:58
|
ke...@us... writes: | >| 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. | | One way you can reduce the impact of the change even for FreeBSD users | is not to copy the DHCP tag into a buffer, but rather save a pointer to | the location in the DHCP buffer and the length. The DHCP buffer is valid | right up to the moment control is handed over to the OS. As a side | effect you don't need to test for buffer overflow since Etherboot has | told DHCP how big a reply it can take so the DHCP server will ensure | that the reply fits in the buffer. This way you can replace the 1024 | byte global buffer with a pointer and an int. I tried that but it broke the DHCP buffer and then the resulting parsing. The issue is that I need a null-terminated string. I tried to null terminate the string and set a pointer to that. It broke parsing anything after that string. Now I might have had an off by one error and I will try it again. However, isc-dhcp distribution had a "bug" for a while in that it took the length literally and if the that string was null terminated your parameter would be returned as "<string>/000" which messed up things if it was your domain name for example. We this was required to make some Windows platform work. Several of us went round and round with Ted on this and he refused to change his position (even though by accident prior versions didn't have this problem). Strangely this has been fixed in a different way later on with no mention of why. So I'm a little nervous if we can really assume space for a null terminated string. | Another strategy is to allocate the buffer in a known memory location. | Since all of 0x90000-0x9ffff is off limits to the booted OS, you could | use say 0x93000 which is just below the Etherboot code. That might be a reasonable thing to do. Doug A. |
