[Etherboot-developers] Proposal: header separated images
Brought to you by:
marty_connor,
stefanhajnoczi
|
From: <ke...@us...> - 2003-03-01 23:35:53
|
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. |