qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2, Ping] SMBIOS: Upgrade Type17 to v2.3, add Ty


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH v2, Ping] SMBIOS: Upgrade Type17 to v2.3, add Type2
Date: Thu, 20 Feb 2014 19:07:33 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131118 Thunderbird/17.0.11

On 02/20/14 16:38, 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 ?

I have no clue about the technical feasibility. You'll probably only
know if you try it :)

Regarding licensing, IIRC Michael ported the ACPI code by:
- posting the qemu patch on both qemu-devel and the seabios list,
- CC'd all people who ever modified the seabios files being ported
  (this is easy with "git log")
- asked all CC'd people to respond with an Acked-by if they agreed to
  relicense their seabios contribs.

Laszlo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]