On Thu, Feb 20, 2014 at 04:27:27PM +0100, Gerd Hoffmann wrote:
On Mi, 2014-02-19 at 15:40 -0500, Gabriel L. Somlo wrote:
So I gave up on that relatively quickly, as there's no easy and convenient way to "harvest" a binary of just one table type from a host that works the way I want it... :(
"dmidecode --type 2" ?
That doesn't work with --dump-bin, to get me something I could just load with "-smbios file=<foo>".
On Wed, Feb 19, 2014 at 11:20:37PM +0100, Laszlo Ersek wrote:
If you want to export a new table whole-sale (SMBIOS_TABLE_ENTRY), then you don't have to modify SeaBIOS. However, in qemu:
- you either need to pass single-table blobs on the qemu command
line, or
- patch qemu so that it internally prepares the *complete* table for
the boot firmware (meaning you must encode knowledge about formatted vs. unformatted fields in qemu -- you must set up the unformatted area and the string indices yourself). (*)
You have to encode the formatted vs. unformatted knowledge *somewhere*. You can push it around (qemu command line, qemu code, seabios code), but you have to encode it explicitly somewhere.
(Writing the SMBIOS patches for OVMF (type0 and type1) took me three days of *uninterrupted* misery ^W coding.)
Preferably, (*) should be implemented, because then SeaBIOS and OVMF can both profit immediately. O:-)
At this point, the question is "cut'n'paste from SeaBIOS" vs. rewrite the table generation routines from scratch in QEMU? I remember ACPI was mostly cut'n'pasted into QEMU, so would that be an OK starting point for SMBIOS as well ? I looked at licenses, and the SeaBIOS smbios.c file is gplv3, whereas the current smbios.c in QEMU is some combination of gplv2 and gplv2+. Any thoughts on whether that's a problem, legally speaking ?
Thanks, --Gabriel