Thread: [Etherboot-discuss] .lkrn Build Target Command-Line & InitRD Support
Brought to you by:
marty_connor,
stefanhajnoczi
From: Miller, S. <Sha...@yr...> - 2009-01-03 04:27:10
|
Hey all, I'd really like to see the gPXE .lkrn build targets support a command-line and an initrd as described by hpa in Linux' boot protocol specification in linux/Documentation/i386/boot.txt. I see that in gPXE 0.9.6+, the slots for these are accounted for in gpxe/src/arch/i386/prefix/lkrnprefix.S. An initrd could become a "pre-fetched" image for use in gPXE. This allows, for example, one gPXE with many gPXE scripts on some boot media, with the boot-loader responsible for choosing which script gPXE should run. Some questions: - How should an initrd be found by gPXE? -- Should the initrd memory be marked as reserved? -- Should the initrd be copied from wherever a boot-loader puts it to a region that's allocated by gPXE proper? - Should real-mode assembly code check for an initrd and simply copy it to a position before/after gPXE's relocation position? - Should an embedded image remain as "img0" and an initrd image become "img1"? How about compatibility with Stefan's multiple embedded images branch? - To prevent any unnecessary checking/code from appearing in non-.lkrn build targets, should this be implemented with table linking magic, or again should real-mode prefix code try to accomplish as much as possible? - Command-line could be as simple as a single gPXE command which is run just prior to gPXE autoboot() time Please let me know what you all think. Thank you for your time, - Shao Miller |
From: Stefan H. <ste...@gm...> - 2009-01-04 10:38:44
|
On Sat, Jan 3, 2009 at 4:26 AM, Miller, Shao <Sha...@yr...> wrote: > - How should an initrd be found by gPXE? > -- Should the initrd memory be marked as reserved? > -- Should the initrd be copied from wherever a boot-loader puts it to a > region that's allocated by gPXE proper? > - Should real-mode assembly code check for an initrd and simply copy it > to a position before/after gPXE's relocation position? > - To prevent any unnecessary checking/code from appearing in non-.lkrn > build targets, should this be implemented with table linking magic, or > again should real-mode prefix code try to accomplish as much as > possible? I propose adding arguments to main() to allow for a command-line and a preloaded image. Other prefixes could use this interface too in the future. Prefixes can be kept simple by passing pointers to "external" memory (i.e. not gPXE .text or .data) and main() has to copy them to a known safe place before using them. This avoids having to do too much work in the prefix before gPXE is initialized properly. An alternative to modifying main() would be to stash the pointers to command-line/initrd and have an init_fn (see include/gpxe/init.h) to grab the stashed values and copy from them as described above. This may allow command-line/initrd to be an optional feature which can be compiled out to save space. > - Should an embedded image remain as "img0" and an initrd image become > "img1"? How about compatibility with Stefan's multiple embedded images > branch? The initrd should take priority over embedded images (i.e. embedded images start at "img1" instead of "img0"). If the bootloader is configured with an initrd to influence gPXE's behavior, then it is counter-intuitive to stash away the initrd and autoboot the embedded image instead. Embedded images have no knowledge of the initrd, but the initrd could have knowledge of the embedded images :). Stefan |