From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mssmx-0004Cn-UY for qemu-devel@nongnu.org; Wed, 30 Sep 2009 02:35:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mssmt-0004Ao-0P for qemu-devel@nongnu.org; Wed, 30 Sep 2009 02:35:47 -0400 Received: from [199.232.76.173] (port=43588 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mssms-0004Ah-Q6 for qemu-devel@nongnu.org; Wed, 30 Sep 2009 02:35:42 -0400 Received: from mx20.gnu.org ([199.232.41.8]:11955) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mssms-00054p-2U for qemu-devel@nongnu.org; Wed, 30 Sep 2009 02:35:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mssmq-00021z-AV for qemu-devel@nongnu.org; Wed, 30 Sep 2009 02:35:40 -0400 Date: Wed, 30 Sep 2009 08:35:35 +0200 From: Gleb Natapov Message-ID: <20090930063535.GA10746@redhat.com> References: <20090914125141.GB30746@redhat.com> <20090915000824.GA16210@morn.localdomain> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090930010946.GA29859@morn.localdomain> Subject: [Qemu-devel] Re: [PATCH][SEABIOS] Move qemu config port access functions into separate file. List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: qemu-devel@nongnu.org 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 format > > 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 for > > coreboot and qemu the API will have to be general enough to accommodate > > 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. On 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. I think it would be nice to have one api for getting > config items for both qemu and coreboot - something like > get_config_u32("ShowBootMenu"). On 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. -- Gleb.