Re: [Qemu-devel] [QEMU v6 PATCH 00/17] SMBIOS: build full tables in QEMU

[Gabriel L. Somlo]

On Thu, Apr 17, 2014 at 10:31:15AM +0200, Gerd Hoffmann wrote:
> > OK, so right now I'm parsing the "version" argument to what is
> > currently smbios_set_type1_defaults() (and will become
> > smbios_set_defaults() after patching).
> 
> No, don't parse stuff please.  Have a look at pc_piix.c, how
> smbios_type1_defaults is handled there.  It's true by default, and
> pc_compat_1_7 (called for 1.7+older machine types) flips it to false.
> 
> We'll add a new variable here, say smbios_generate_table_blob, default
> it to true, then flip to false in the (to be added with the 2.1 machine
> type) pc_compat_2_0 function.  Same in pc_q35.c.
> 
> Then you can simply use the new global variable.

There's one problem I don't see a way around:

Command line options are processed before machine types are
initialized.

This means smbios_entry_add() runs *before* anyone has had a chance to
properly set any global variable regarding whether we're in smbios
legacy mode, or whether we're doing aggregate tables plus entry point.

This means smbios_entry_add() can't know whether a binary blob
received on the command line needs to be added with a table wrapper
for legacy mode, or without one to the aggregate blob for types 2.1
and later...


Guess I could add binary blobs from the command line to *both* legacy
"smbios_entries", and to a new "smbios_aggregate_table", with and
without a SMBIOS_TABLE_ENTRY wrapper, respectively. Then, once
smbios_set_defaults() runs, I can free the one I don't need...


Can anyone think of a less repugnant way to work around this, maybe
something not quite as far "beyond the environment" ?   ;) 

Thanks,
--Gabriel