[gPXE-devel] [PATCH][lkrn] add cmdline and ramdisk support

[Wu Fengguang]

Hi Shao,

On Tue, Jun 01, 2010 at 11:39:51PM +0800, Miller, Shao wrote:
> Perhaps a better way to interpret a gPXE .lkrn command-line passed by a
> previous boot-loader might be:
> 
> Parse filename=XXX and root-path=XXX options.
> 
> This removes the assumption (of my patch) that the gPXE script feature
> is available and also removes the assumption that gPXE CLI commands are
> available at all.
> 
> Unfortunately, it does not address the case where you wish to boot a
> kernel and initrd.  However, additionally processing module=XXX (or
> image=XXX) might be a way to deal with that, since the gPXE 'initrd'
> command is really just an alias for 'imgfetch'.
> 
> Related to the last paragraph would be the idea of allowing gPXE
> encapsulated options to include additional modules/images.  Then a DHCP
> server can pass a kernel in the filename option and an initrd in such an
> encapsulated option.  If we implement that, then the "module=XXX"
> processing just mentioned becomes a simple tie to a DHCP option, just as
> "filename=XXX" and "root-path=XXX" processing would be.

Hmm, autoboot defaults to the TFTP download protocol given the
filename option. This drops a big strength of gPXE.. And you'll need
another option for kernel parameters (and need to handle spaces in
between).

So it looks more straightforward to go the script way.

> There was a little bit of recent discussion[1][2] surrounding the
> occasional need to do more of what gPXE allows from the [smallish] space
> that conventional PXE environments provide.  In that thread, I
> suggested[3] a protocol that could build gPXE scripts on-the-fly from a
> URI.  Such a protocol could be tied to the incorporation of the gPXE
> scripting feature during build.

You mean the x_cmd:// URI?  That's pretty clean for implementation,
however sounds ugly as a user interface. 

How about this cmdline syntax:

        APPEND  #!gpxe; dhcp net0; kernel URL root=...; boot;

- the '#!gpxe' declares the start of a gPXE script (this will exclude
  the BOOT_IMAGE=... added by GRUB)

- the followed ';' declares that the semicolon will be treated as
  the DELIMITER (think about the '/' in :s/a/b/ for vim)

- each gPXE must end with the DELIMITER, ie. the last ';' is not
  optional (this will exclude the BOOT_IMAGE=... appended by PXELinux)
 
> I'd really enjoy reading what the gPXE core developer usual suspects
> have to offer. :)

Me too :)

Thanks,
Fengguang

> [1] http://etherboot.org/pipermail/gpxe/2010-May/001039.html
> [2] http://etherboot.org/pipermail/gpxe-devel/2010-May/000197.html
> [3] http://etherboot.org/pipermail/gpxe-devel/2010-May/000203.htm