[Etherboot-developers] Proposal: header separated images

[<ke...@us...>]

One of the criticisms of Etherboot is the need to prepare the boot image
by running a preprocessing step to the image to be loaded. PXE avoids
this by loading a NBP which instructs the boot code what to load next.
In this way, a NBP can load an untagged Linux kernel.

In the long run it would be nice if Linux kernels were built to be
netboot ready, but there may be a way this can be done in Etherboot
without implementing PXE.

Currently the load process reads the directory block which instructs
Etherboot what segments to expect in the TFTP stream and where to put
them in memory.

Define a PT_NOTE record that says to Etherboot: Replace the current
filename with this string, then continue the load from that stream
without replacing the directory block.

A header for a Linux kernel would look like this (in pseudo-code):

	PT_LOAD trampoline
	PT_LOAD kernel parameters
	PT_NOTE vmlinuz-2.4.20
	PT_LOAD floppy sector
	PT_LOAD setup sectors
	PT_LOAD kernel
	PT_LOAD ramdisk (if present)
	PT_NOTE checksum

Sort of like a CHAIN command embedded in an ELF PT_NOTE.

To implement this, there would have to be an extra variable to indicate
this state after reading the header stream. When the header stream
ends, instead of jumping into the code, it does a TFTP for the next
file, skips the header validity checks, and continues the load using the
existing directory block where it left off restarting at the floppy
sector.

We still have to load the trampoline and the kernel parameters from this
header file due to the need to add kernel parameters and to move the
ramdisk.

This feature could also be used for non-Linux images. Perhaps it could
be generalised to any number of such PT_NOTEs. Then it becomes a sort of
INCLUDE command.

A drawback is that a single 512 byte block may not be enough to hold the
directory, expecially if the filename is long. Maybe a longer/variable
length directory block is needed for futureproofing.

Another drawback is that you still have to run a program to create the
header file initially, and anytime the kernel image changes. You can't
use a generic header file because it doesn't have the smarts to look at
the kernel and see where the kernel ends and the ramdisk starts. This
may be a serious drawback, if you need to run a program when why not tag
it like we do now.

Open for comment.