[gPXE-devel] More Scripting Discussion

Shao Miller Shao.Miller at yrdsb.edu.on.ca
Fri Mar 19 17:13:58 EDT 2010


Stefan Hajnoczi wrote:
>
> =Control Flow=
>
> ...Although the structured approach is more user-friendly, the low-level
> approach is reasonably usable and meets our code size requirements to
> fit into a 64 KB ROM more readily...
>

Personally, I'd like to see gPXE scripting Turing-complete.  Then the 
user can implement their favourite video game, even if they can't use it 
as a video game. :)  For the two constraints above:
- User-friendly
- Low cost-size cost

We could potentially benefit by putting the code-size cost onus on the 
script.  A "standard library" could be developed, which users 
_who_want_it_ can include it in their script or call it or whatever.  
Minimally, gPXE would then need just enough additions to allow for the 
scripting language itself to be usefully extended into a complete and 
user-friendly system.

Something that might come in handy might be "aliases," where something 
can appear to be a command, but is really a substitution for something 
else.  Here's a patch which provides such[1].  For example, you can do:

    gPXE> set echo echo
    gPXE> set hello hello
    gPXE> set __foo:hex ${echo:hex}:20:${hello:hex}
    gPXE> foo
    hello

Then we might get into things like wanting to call/return and passing 
arguments.  The point is that if you can extend the language from within 
the language, you can push the code size burden onto the script and not 
gPXE, but also provide a user-friendly interface (even different flavours!).

A possible way to extend the language is by having a minimal "dot-language":

    gPXE> . +
    gPXE> . -
    gPXE> # Choose your stack
    gPXE> . working_setting
    gPXE> # Copy a setting (stack)
    gPXE> . from_setting to_setting
    gPXE> . command_to_define : expansion
    gPXE> . condition_setting ? true_command
    gPXE> . condition_setting ! else_command

etc.  My hope would be that parsing code cost could be minimized with 
something like, though extending the language from within the language 
is just an idea to share, not a recommendation.

> ...I therefore support getting
> if/goto into gPXE - it will allow a wider audience to do
> boot.kernel.org-style magic.
>

Agreed.  'if' functionality can be roughly matched without being 
implemented in gPXE code, but is ugly and quirky, so an in-code 
implementation would be nice.  I like yours, Stefan. :)

- Shao Miller

[1] 
http://git.etherboot.org/?p=people/sha0/gpxe.git;a=commitdiff;h=582e0eb41454b5ce15367fa39964369d9aa0aee9


More information about the gPXE-devel mailing list