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