|
From: <ke...@us...> - 2001-06-12 04:06:55
|
>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
The reason a mk{nbi,elf}-linux is needed is because the Linux kernel
image has a strange layout which would require code to understand. Also
the kernel image has no provision for storing any parameters. This
parsing code doesn't belong in Etherboot, which should be just a loader.
A similar argument applies to DOS images. So either the extra work is
done by an image builder and a third stage, or as in PXE you load a
target specific second stage which does the rest.
>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.
Fair enough, but Etherboot is not PXE. If somebody wants to hack PXE
functionality in, feel free to contribute.
>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.
Well it almost works like that actually, Etherboot does a request, and
the kernel can also do a request, and user space programs can do a
request too. In fact, if you want to get things like NIS server or the
other options which Etherboot doesn't use, you have to make an extra
request. Only the third stage doesn't do any requests at the moment.
Etherboot's third stage isn't an independent executable, more like a
chained segment.
>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.
To actually get significantly more space you would have to use the
overload option to tell the DHCP server not to send the filename and
hostname in the reserved fields, but as options, so that the reserved
fields can be collapsed. Overall you are limited by the 1500 bytes of
the Ethernet packet anyway. And the 1 byte length field.
|
