OK, so I have the "legacy" (field-by-field, types 0 and 1 only) code back in, right next to the new aggregate-smbios-table-plus-entrypoint code, tested and apparently working fine.
Before I get carried away with "git rebase", do we still want to go through the whole patch sequence of generating aggregate tables identical to what SeaBIOS would have (including e.g. type 20), then drop type 20 and upgrade to smbios spec v2.8, etc ?
Since we're keeping the legacy code, I can add in the new code (only for machine types >= 2.1) directly as smbios spec v2.8 compliant (mainly without adding in generation for type 20, then ripping it right back out again).
This would result in a smaller, cleaner patch set. Any objections ?
On Wed, Apr 16, 2014 at 08:41:51AM +0200, Gerd Hoffmann wrote:
Global variable, simliar to smbios_type1_defaults. machine type init code will set it accordingly. smbios code just does "if (smbios_generate_tables) { ... }" (or however we name this).
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).
This gets passed in by pc_piix.c or pc_q35.c from args->machine->name, and comes in turn from the various machine definitions in pc_[q35|piix].c.
I noticed some of the older QEMUMachine structures have a hw_version member set, but the latest I could find being set explicitly is 1.0, and only in pc_piix.c.
On current (2.0) piix and q35 machines, the hw_version field is NULL, is that a bug or a feature ?
If the latter (feature), is there a better way to find out which side of "2.1" I'm currently on than by scraping it out of args->machine->name ?
Thanks, --Gabriel