|
From: Doug A. <amb...@am...> - 2001-06-12 03:43:47
|
Eric W. Biederman writes:
| Doug Ambrisko <amb...@am...> writes:
|
| > Donald J Christensen writes:
| > | There is a third stage bootloader program that is included in a
| > | tagged image by mk{nbi,elf}-linux. That is where the option processing
| > | currently happens, I believe. The size restrictions are more relaxed
| > | on this than on Etherboot (with a little effort, you can easily get
| > | 64KB to run it in.)
| > |
| > | I would suggest modifying first32.c or adding a new implementation that
| > | does what you need.
| >
| > So you are saying that the third stage loader can access the network to
| > send and receive packets? Before when I looked at it I don't recall
| > it doing that.
|
| The third stage has access to the DHCP results so it shouldn't need
| to do any send/receive. Just parse out the DHCP options.
That doesn't really buy anything. Might just as well pass that string
into the kernel and let the kernel parse them out. I don't see a point
for a 3rd stage loader that doesn't do anything. It's easy enough to
load things into memory and then jump into the image. Then you don't
have to do a mk{nbi,elf}-linux which seems kind of strange to me but then
it seems strange to me to have to run lilo whenever you build a kernel or
want to load a different kernel vs. just loading a kernel I want. I just
point /tftpboo/kernel<foo> into my kernel tree and it gets auto updated.
It's an easy way with the menu stuff to manage several different kernels.
Then there is the issue the kernel might want a different set of parameters
then EtherBoot. To keep things to a minimum EtherBoot should only request
the things it deals with. The 3rd stage should only request the things it
needs. The kernel should only request the things it needs. Then at the
OS level it should only request the things it needs.
Obviously this is going to the extreme but DHCP options are starting to
get very long so now I break them out on vendor identifiers so my DHCP
packets are shorter.
PXE UNDI is kind-of nice since it loads a loader and then an image.
So for DOS you put a raw disk image in the tftpboot area and you
can mount and modify that on the fly.
Doug A.
|
