qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin O'Connor <kevin@koconnor.net>
To: Gleb Natapov <gleb@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH][SEABIOS] Move qemu config port access functions into separate file.
Date: Fri, 2 Oct 2009 12:52:13 -0400	[thread overview]
Message-ID: <20091002165213.GA13398@morn.localdomain> (raw)
In-Reply-To: <20091002140311.GC17326@redhat.com>

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

  reply	other threads:[~2009-10-02 16:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-14 12:51 [Qemu-devel] [PATCH][SEABIOS] Move qemu config port access functions into separate file Gleb Natapov
2009-09-15  0:08 ` [Qemu-devel] " Kevin O'Connor
2009-09-15  5:43   ` Gleb Natapov
2009-09-16  2:02     ` Kevin O'Connor
2009-09-17  9:57       ` Gleb Natapov
2009-09-18  1:24         ` Kevin O'Connor
2009-09-18 10:01           ` Gleb Natapov
2009-09-19 15:16             ` Kevin O'Connor
2009-09-19 17:56               ` Gleb Natapov
2009-09-30  1:09                 ` Kevin O'Connor
2009-09-30  6:35                   ` Gleb Natapov
2009-09-30 17:17                     ` Blue Swirl
2009-09-30 17:31                       ` Gleb Natapov
2009-10-02  1:08                       ` Kevin O'Connor
2009-10-01 16:35   ` Gleb Natapov
2009-10-02  0:51     ` Kevin O'Connor
2009-10-02 14:03       ` Gleb Natapov
2009-10-02 16:52         ` Kevin O'Connor [this message]
2009-10-02 18:10           ` Gleb Natapov
2009-10-02 19:31             ` Kevin O'Connor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091002165213.GA13398@morn.localdomain \
    --to=kevin@koconnor.net \
    --cc=gleb@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).