qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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: Sat, 19 Sep 2009 20:56:55 +0300	[thread overview]
Message-ID: <20090919175655.GA4955@redhat.com> (raw)
In-Reply-To: <20090919151641.GC28926@morn.localdomain>

On Sat, Sep 19, 2009 at 11:16:41AM -0400, Kevin O'Connor wrote:
> On Fri, Sep 18, 2009 at 01:01:20PM +0300, Gleb Natapov wrote:
> > On Thu, Sep 17, 2009 at 09:24:11PM -0400, Kevin O'Connor wrote:
> > > On coreboot there is the Coreboot FileSystem (CBFS).  Basically, the
> > > flash stores a series of named files, and SeaBIOS knows how to iterate
> > > through them.  So, for instance, one might find the file
> > > "pci1013,00b8.rom" which contains an option rom for pci device
> > > 1013:00b8, or one might find "floppyimg/FreeDOS" with an image of a
> > > floppy to be emulated.
> > > 
> > > So, ideally qemu would do something similar.  Maybe something like:
> > Qemu already does something different. For instance acpi tables are
> > transfered as stream formated like this:
> > <table count><1 table length><table data><2 table length><table data>
> > ...<n table length><table data>
> 
> Maybe a stream could be introduced with something like:
> <name><len><data> <name2><len2><data2> ...
> 
The format is already set. The are two ports. You write option id in
first port and you read option value from second one. The value format
is different for each option. Additional acpi table format is like I
described above. If we want to use the same APIs for config access for
coreboot and qemu the API will have to be general enough to accommodate
both approaches. Changing formats is not an option at this stage.

> > I don't think qemu should expose file system API to a BIOS.
> 
> To be clear, I'm not proposing exposing the system's filesystem to the
> guest.
> 
> It's really just a way of getting name=value pairs.  If there is a
> different way to do this then that's fine.  Ideally, to fit with
> SeaBIOS' current code, there would be a way to obtain the size and
> data for a given "name" along with an ability to iterate through the
> list of "names" available.
> 
You can obtain size for acpi tables by reading the whole data first time
just for calculating the data size and discarding the data. But I don't see
the point of doing it. The format was specifically designed to allow
reading one table at a time and placing it in its final place in memory.

--
			Gleb.

  reply	other threads:[~2009-09-19 17: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
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 [this message]
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=20090919175655.GA4955@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).