qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH][SEABIOS] Move qemu config port access functions


From: Gleb Natapov
Subject: [Qemu-devel] Re: [PATCH][SEABIOS] Move qemu config port access functions into separate file.
Date: Wed, 30 Sep 2009 08:35:35 +0200

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:
> > > <name><len><data> <name2><len2><data2> ...
> > > 
> > 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.




reply via email to

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