[gPXE-devel] [PATCH] [scriptlet] Add "scriptlet" NonVolatile Option (NVO) support.

[Glenn Brown]

Marty,

I look forward to the scripting discussion.

I have used sha0's "loopif 1".  It looks like very good insurance 
against encountering a BIOS that hangs after failed boots.  I plan to 
built the loopif patch into our default ROMs.

I'm developing a pretty good understanding of the "settings" 
infrastructure.  My motivation was that I wanted to hide the smbios 
settings in the text UI when the user does "config net0.nvo" and I 
wanted to disable editing of read-only fields, such as "manufacturer" 
which comes from smbios, and I wanted to hide unset read-only settings 
from smbios.  However, I ran into some interesting obstacles:
1) The "setting" structure and SETTINGS table are metadata about which
    settings exist within gPXE, but omit any information about which
    of the settings is associated with each 'settings' structure.
2) There is currently no standard way to know in advance if you
    can store or fetch a particular setting in a given context,
    other than trying to store or fetch and looking at the return value.
(1) meant I could not modify the settings UI to list just 
context-relevant variables.  (2) meant I could not disable editing or 
hide read-only settings... although ultimately the nvo mechanism allows 
all settings to be written.

This leads me to a question: who fully understands the 'tag' field usage 
in the settings structure?  I ask because I'm hopeful that I might 
leverage this field to address (1) and (2) above with very little 
overhead.  Without a clear understanding of 'tag' field semantics, 
however, such changes would be risky hacks.

Thanks,
--Glenn