[Qemu-devel] Re: [PATCH][SEABIOS] Move qemu config port access functions into separate file.

[Gleb Natapov]

On Fri, Oct 02, 2009 at 12:52:13PM -0400, Kevin O'Connor wrote:
> On Fri, Oct 02, 2009 at 04:03:11PM +0200, Gleb Natapov wrote:
> > > Having to write these wrapper functions is tedious, which is why it
> > > would be nice if I could get a name/value pair directly from qemu.
> > > 
> > And proposed get_config_u32() will look like this:
> > u32 get_config_u32(const char *name, u32 default)
> > {
> >     if (COREBOOT)
> >             return get_cbfs_config_u32("ShowBootMenu", 1);
> >     else
> >             return get_qemu_config_u32("ShowBootMenu", 1);
> > }
> 
> It would look like:
> u32 get_config_u32(const char *name, u32 default)
> {
>       if (CONFIG_COREBOOT)
>               return get_cbfs_config_u32(name, default);
>       else
>               return get_qemu_config_u32(name, default);
> }
Correct, wrong cut&paste on my part ;)

> 
> It is a wrapper but there would be just one instead of one wrapper per
> config option.
> 
How many config options do you expect? And as I said having function
like cfg_show_boot_menu() allow to have more flexible defaults handling.
If we will go this route I prefer
bool get_config_u32(const char *name, u32 *val)
interface. And will still need common interface for table loading. I
prefer to implement qemu way in qemu_table_load() and don't jump
through the hoops trying to make it look like coreboot.

> > > If qemu can provide a "stream" with a text config file in it, that's
> > > okay too.  Basically, that's what I'm thinking of doing on coreboot.
> [...]
> > This kind of interface doesn't make any sense to qemu. Qemu doesn't have
> > shared memory with a guest to store config as a text file like coreboot 
> > does.
> 
> I agree it's not compelling for qemu - I'm bringing it up as a
> possibility.  As above, I don't think it would require shared memory -
> the existing "stream" interface would be sufficient.
Qemu already has interface. That is the interface that we have to use.
Discussing purely theoretical possibilities just distract us from
searching for solution.

> 
> > That is why qemu chose to provide name/value interface.
> 
> I'm a bit confused here.  As near as I can tell, qemu has an
> int_id->value mapping.  What I'd like to see is a string_name->value
What is the difference? Why do you care if it is int->value or
string->value? I can easily map string to int in seabios qemu config
functions so for the rest of seabios it will look just like string->value.
I don't see the point of doing this though.

> mapping.  The int_id isn't flexible because I can't share ids across
> products.
What do you mean? What products?

> 
> If qemu is willing to add this to the backend (ie, the emulator passes
> the info to the bios as string_name->value), then great.  The actual
Qemu is not (or shouldn't be) developed in a lockstep with a bios. Bios
should be flexible enough to support older or newer qemus. Seabios
should treat qemu just like any other HW mobo. Even if we add something to
qemu now we want to support older qemus too.

> specifics of how it is done isn't of great concern to me.  If not,
> then lets go forward with the basic int_id support.  The internal API
> for coreboot can be figured out when the coreboot config support is
> added.
> 
You mean like in my first patch? I can resend it with all other points
addressed.

--
                        Gleb.