Alex Williamson wrote:
Hi Anthony,
On Mon, 2009-04-06 at 14:50 -0500, Anthony Liguori wrote:
Alex Williamson wrote:
I know we have to support blobs because of OEM specific smbios entries,
but there are a number of common ones that it would probably be good to
specify in a less user-unfriendly way. What do you think?
Yeah, I'll admit this is a pretty unfriendly interface. I get from your
comment on the other part of the patch that you'd prefer not to get into
the mess of having both binary blobs and command line switches
augmenting the blobs. This seems reasonable, but also means that we
need a way to fully define the tables we generate from the command line.
For a type 0 entry, that might mean the following set of switches:
-bios-version, -bios-date, -bios-characteristics, -bios-release
You could go one level higher:
-smbios type=0,bios-version='1.0',bios-date='2009/10/20' etc.
I'm sure I'm missing some, plus we might want to allow the memory and
processor entries to have some fields changed. Do we want to add that
many switches and means to access them from the rombios?
I think it's okay to start with some of the more common tables and
provide the parsing in QEMU. We could then introduce humanize more
tables down the road as people saw fit.
At the end of the day, I'm most interested in the tables that are going
to be frequently used by management applications. That is, the tables
that are required for things like SVVP certification should be specified
in a human readable format that QEMU can build reasonable defaults for
and management tools can override.
I'm torn between exposing the tables directly to the firmware or
providing a higher level interface. I really don't like -uuid
overriding a binary blob though so I'd prefer to avoid that. -uuid
should only be respected if using the QEMU generated version of the
SMBIOS table. I'll defer to whatever you think is better what is
exposed in the firmware interface as I can see arguments for both.
--
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
