On Thu, Feb 20, 2014 at 10:38:04AM -0500, Gabriel L. Somlo wrote: > 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 ?
s/gplv3/lgplv3/, but same question :) Thanks, --G
