From: Gleb Natapov <gleb@redhat.com>
To: Kevin O'Connor <kevin@koconnor.net>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH][SEABIOS] Move qemu config port access functions into separate file.
Date: Thu, 17 Sep 2009 12:57:28 +0300 [thread overview]
Message-ID: <20090917095728.GN23157@redhat.com> (raw)
In-Reply-To: <20090916020259.GA18131@morn.localdomain>
On Tue, Sep 15, 2009 at 10:02:59PM -0400, Kevin O'Connor wrote:
> On Tue, Sep 15, 2009 at 08:43:39AM +0300, Gleb Natapov wrote:
> > On Mon, Sep 14, 2009 at 08:08:24PM -0400, Kevin O'Connor wrote:
> > > As an aside, it would be good to have a conversation on general BIOS
> > > configuration options. These types of settings are going to be useful
> > > on real hardware also - it would be nice to come up with a scheme that
> > > would work on qemu and coreboot. Maybe something like
> > > get_config_u32("ShowBootMenu") - where on qemu it would get the info
> > > from the qemu port but on coreboot it would pull the setting from the
> > > coreboot flash filesystem.
> > >
> > Lets have conversation now. Sounds useful to me. Do you want to use
> > strings as option names though? They add to BIOS image size and it is
> > limited, no?
>
> My preference is strings - I think the long-term flexibility they
> provide is worth the slight additional overhead they require.
>
> Currently, SeaBIOS is just under 64K -- if features continue to get
> added (eg, usb keyboard/boot) then it will likely creep into the
> e-segment. I don't foresee any hard limits on space coming up.
>
Fine by me.
The configuration interface should be able to read streams of data
though. Qemu uses it to pass additional ACPI tables for instance. So
it not just simple key->value interface. get_config_u32("ShowBootMenu")
will work for simple cases but how can we express stream semantic? May be:
table_count = get_config_u16("AdditionalAcpiCount")
select_config("AdditionalAcpiTables");
for (i=0; i<table_count; i++) {
len = config_read(table[i], table_len[i]);
}
--
Gleb.
next prev parent reply other threads:[~2009-09-17 9:57 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 [this message]
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
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=20090917095728.GN23157@redhat.com \
--to=gleb@redhat.com \
--cc=kevin@koconnor.net \
--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).