Overriding default config with nvram?

[Blue Swirl]

Hi,

I'm adding support for nvram variables to Qemu (see attached patches), like:
qemu-system-sparc -prom-env "boot-device=zorg"

But this only works if the variable does not have any default value in
nvram.fs. I'd like to change this so that the nvram values override
defaults, but how?

For example:
qemu-system-sparc -boot n -prom-env "boot-device=foobar" -prom-env
"boot-device-foobar=foobar" -nographic -monitor stdio -hda /dev/null
Nvram id QEMU_BIOS, version 1, machine id 0x80
CPUs: 1
Welcome to OpenBIOS v1.0RC1 built on Apr 29 2007 07:39
  Type 'help' for detailed information

[sparc] Booting file 'net' without parameters.

0 > printenv
name                      "options"
boot-from                 "disk"
boot-device               "disk"
boot-device-foobar        "foobar"
boot-args                 ""
[cut]

Here boot-device is overridden to "disk" somewhere later but
boot-device-foobar survives.

[e-mail] wrote:
> Hi,
>
> I'm adding support for nvram variables to Qemu (see attached patches), 
> like:
> qemu-system-sparc -prom-env "boot-device=zorg"
>
> But this only works if the variable does not have any default value in
> nvram.fs. I'd like to change this so that the nvram values override
> defaults, but how?

Just an idea, off the top of my head, without having gone too deeply 
into the matter.
TIoLI, FWIW...

Have a run-time file in which Qemu keeps its current NVRAM contents.  
Make the
name of the file a variable, with a default if not specified.  If the 
file does not exist, it
gets created with its variables' initial values set to their default 
settings.  It is, in effect,
Qemu's virtual emulation of NVRAM; it gets updated in the course of the 
emulation
run as values get changed, and remains available for subsequent runs.

qemu-system-<ARCH> -env-emu nvfile=mynvram.xxx

I expect that this will give greater continuity, flexibility and access 
than specifying
individual variables' values from the command-line, and will obviate any 
need to
keep track of changes across the course of a series of runs.

(Please note that I'm "out of the game" at present, but still available 
for an occasional
shout-out "from the stands".  Hello to all my friends and acquaintances!)

[Blue Swirl]

> Have a run-time file in which Qemu keeps its current NVRAM contents.
> Make the
> name of the file a variable, with a default if not specified.  If the
> file does not exist, it
> gets created with its variables' initial values set to their default
> settings.  It is, in effect,
> Qemu's virtual emulation of NVRAM; it gets updated in the course of the
> emulation
> run as values get changed, and remains available for subsequent runs.

The savevm and loadvm commands in the CVS version of Qemu handle also
the NVRAM contents. So the net effect is similar, except that the
files are not separate. That could be addressed by creating some kind
of disassembly and assembly tools for the vm images.