From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mt327-00038P-J7 for qemu-devel@nongnu.org; Wed, 30 Sep 2009 13:32:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mt323-00032j-RR for qemu-devel@nongnu.org; Wed, 30 Sep 2009 13:32:07 -0400 Received: from [199.232.76.173] (port=40849 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mt323-00032P-LT for qemu-devel@nongnu.org; Wed, 30 Sep 2009 13:32:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38289) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mt321-0002Tk-7a for qemu-devel@nongnu.org; Wed, 30 Sep 2009 13:32:01 -0400 Date: Wed, 30 Sep 2009 19:31:56 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: [PATCH][SEABIOS] Move qemu config port access functions into separate file. Message-ID: <20090930173156.GO9832@redhat.com> References: <20090915054339.GD30746@redhat.com> <20090916020259.GA18131@morn.localdomain> <20090917095728.GN23157@redhat.com> <20090918012411.GA23213@morn.localdomain> <20090918100120.GC11921@redhat.com> <20090919151641.GC28926@morn.localdomain> <20090919175655.GA4955@redhat.com> <20090930010946.GA29859@morn.localdomain> <20090930063535.GA10746@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Kevin O'Connor , qemu-devel@nongnu.org On Wed, Sep 30, 2009 at 08:17:26PM +0300, Blue Swirl wrote: > On Wed, Sep 30, 2009 at 9:35 AM, Gleb Natapov wrote: > > On Tue, Sep 29, 2009 at 09:09:46PM -0400, Kevin O'Connor wrote: > >> On Sat, Sep 19, 2009 at 08:56:55PM +0300, Gleb Natapov wrote: > >> > On Sat, Sep 19, 2009 at 11:16:41AM -0400, Kevin O'Connor wrote: > >> > > Maybe a stream could be introduced with something like: > >> > > ... > >> > > > >> > The format is already set. The are two ports. You write option id in > >> > first port and you read option value from second one. The value form= at > >> > is different for each option. Additional acpi table format is like I > >> > described above. If we want to use the same APIs for config access f= or > >> > coreboot and qemu the API will have to be general enough to accommod= ate > >> > both approaches. Changing formats is not an option at this stage. > >> > >> Okay - it doesn't sound like there is much overlap here between qemu > >> and coreboot. =9AOn coreboot cbfs is used for pulling out option roms, > >> executables, and floppy images - none of which have much use under > >> qemu anyway. > >> > >> So, maybe we should just go back to the discussion of a config > >> interface. =9AI think it would be nice to have one api for getting > >> config items for both qemu and coreboot - something like > >> get_config_u32("ShowBootMenu"). =9AOn coreboot that info could then be > >> extracted from cbfs and qemu can get in from the "cfg port". > >> > >> Does that make sense? > >> > > Yes. That is the direction I was going to take. Lest implement simple > > name/value interface first and table loading code will be different. > > If there will be much overlap in table loading code we will unify it > > later. >=20 > The name/value interface could be useful for OpenBIOS too if we want > to avoid using NVRAM for OpenBIOS variables for compatibility. There > should be methods to iterate through all keys and get the byte size of > the value. >=20 > For example, current fw_cfg interface could be extended to allow > string keys in addition to integer keys. There are two types of string keys. Those that you know the length in advance (like uuid) and those you don't. fw_cfg can support second type without additional change by passing as a value. This will be hidden from seabios behind get_config_string() interface of course. -- Gleb.