[SeaBIOS] [PATCH v2, Ping] SMBIOS: Upgrade Type17 to v2.3, add Type2

[Gabriel L. Somlo]

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