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

Marty Connor mdc at etherboot.org
Sun Aug 1 16:53:23 EDT 2010


Hi Glenn,

Sorry for the delay in reviewing yours and Shao's NVS and 
scripting patches.  It's on our radar, and we hope to review
and apply them soon.

Anybody who wants to review and comment on Glenn's patches
is invited to.

/ Marty /

On 6/29/10 6:31 PM, Glenn Brown wrote:
> 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
> 
> 
> 



More information about the gPXE-devel mailing list