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

[Kevin O'Connor]

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);
}

It is a wrapper but there would be just one instead of one wrapper per
config option.

> > 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.

> 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
mapping.  The int_id isn't flexible because I can't share ids across
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
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.

-Kevin