[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH][SEABIOS] Move qemu config port access functions
[Qemu-devel] Re: [PATCH][SEABIOS] Move qemu config port access functions into separate file.
Fri, 2 Oct 2009 12:52:13 -0400
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);
> return get_qemu_config_u32("ShowBootMenu", 1);
It would look like:
u32 get_config_u32(const char *name, u32 default)
return get_cbfs_config_u32(name, default);
return get_qemu_config_u32(name, default);
It is a wrapper but there would be just one instead of one wrapper per
> > 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
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