From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44912) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGY2G-0000KO-Bz for qemu-devel@nongnu.org; Thu, 20 Feb 2014 13:07:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WGY2A-0006f7-Cc for qemu-devel@nongnu.org; Thu, 20 Feb 2014 13:07:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43652) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGY2A-0006ey-7l for qemu-devel@nongnu.org; Thu, 20 Feb 2014 13:07:42 -0500 Message-ID: <53064465.2080302@redhat.com> Date: Thu, 20 Feb 2014 19:07:33 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <20140217160947.GO29329@ERROL.INI.CMU.EDU> <20140217203333.GB30268@morn.localdomain> <1392718893.4724.12.camel@nilsson.home.kraxel.org> <20140218191728.GS29329@ERROL.INI.CMU.EDU> <1392803974.20987.13.camel@nilsson.home.kraxel.org> <20140219204030.GA25087@ERROL.INI.CMU.EDU> <1392910047.9377.3.camel@nilsson.home.kraxel.org> <20140220153803.GD25087@ERROL.INI.CMU.EDU> In-Reply-To: <20140220153803.GD25087@ERROL.INI.CMU.EDU> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2, Ping] SMBIOS: Upgrade Type17 to v2.3, add Type2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" Cc: "Michael S. Tsirkin" , seabios@seabios.org, agraf@suse.de, qemu-devel@nongnu.org, Kevin O'Connor , Gerd Hoffmann , pbonzini@redhat.com 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=". > > 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