On Tue, Apr 15, 2014 at 10:29:26AM +0200, Gerd Hoffmann wrote:
> So, how about this plan:
>
> Leave the old interface code basically as-is. type0 and type1
> individual fields are passed like they are passed today. We don't
> change to to pass full tables, and we don't extend that to new table
> types. Continue to provide these in parallel to the new interface, for
> compatibility with old firmware (and old machine types).
>
> The code to generate complete tables will only be used for
> "etc/smbios/smbios-tables". Only machine types for 2.1 + newer will
> provide them, so with older machine types seabios will continue to
> generate the smbios tables and guest wouldn't notice a difference.
>
> That means to drop patch #6. Patches 4+5+7+8+9+10+11 could be squashed
> together (although it is probably better to leave them separate, even
> though 4..10 will not have any effect until 11 is applied) and
> simplified a bit (don't provide complete tables via old interface).
>
> Comments?
So, basically, leave "uint8_t *smbios_get_table()" unchanged, i.e.
have it generate a blob of field overrides as it does today.
Add "void smbios_get_tables()" as a separate function to generate the
entry point and aggregate smbios table, and then:
if "machine_type < 2.1" then
insert smbios_get_table() into fw_cfg (compat mode)
else
insert smbios_get_tables() blob + entry point (new hotness)
fi
I guess both compat and new smbios_get_table[s] can use the same
default fields set via the command line.
The remaining issue is how to handle "-smbios file=<foo>" blobs; maybe
smbios_set_defaults() can be used to set the version, and then the
command line parser (smbios_entry_add()) would know which kind of table
to insert the blob into, compat or aggregate ?
That being said, how do I even tell the difference between pre- and
post- 2.1 machine types ? Would that be in pc.c, or pc_[q35|piix].c ?
Thanks,
--Gabriel
PS. This should make the patch set a whole lot more compact, as the
main reason in my book for splitting it up into a million pieces was
to avoid confusion related to mixing diff deletions and insertions in
a non-human-readable form; Since now we're talking about mostly
insertions and (almost) no deletions, that should make things quite a
bit easier to follow... :)
