From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel@nongnu.org
Cc: Brian Johnson <bjj4@charter.net>
Subject: Re: [Qemu-devel] Re: [PATCH] Patches from PyQemu project
Date: Tue, 04 Sep 2007 18:34:17 -0500 [thread overview]
Message-ID: <1188948857.6627.2.camel@squirrel> (raw)
In-Reply-To: <20070904222715.GB9977@networkno.de>
On Tue, 2007-09-04 at 23:27 +0100, Thiemo Seufer wrote:
> Brian Johnson wrote:
> [snip]
> >> My initial thought is to make the libraries at the individual device
> >> level.
> >
> > It would be good to have a general mechanism for bus providers, interrupts,
> > APICs, chipsets, etc. as well, so we could emulate fancier architectures
> > than a simple PC (or simple Sparc/MIPS/ARM/etc. box.) For instance, I'd
> > like to emulate multiple PCIe host bridges, each with an APIC and multiple
> > cards, which might contain PCI-to-PCI bridges. And I'd like to emulate
> > NUMA systems with many memory controllers and a complex memory map, with
> > multiple sets of chipset registers. I don't expect qemu to do this off the
> > shelf,
>
> Why not? I would like to see better abstracted and more capable device
> emulations in Qemu.
>
> > but I'd like to avoid hardcoding PC assumptions into the device
> > libraries, so I can code the fancy machines myself and use the I/O as-is.
>
> Then, what does a librar-ized Qemu device with its hardcoded PC
> assumptions help you?
>
> One reason why I don't like the idea is that it introduces a external
> interface which is hard to maintain.
It just depends on how you support the interface. There's really
nothing wrong with having a per-device version #define and making no
guarantees that the interface stays consistent across versions. The
goal isn't to have a third party tool be able to use *any* version of
QEMU's device model but rather to allow it to use *some* version of it
instead of forking it into it's own code base.
However, I don't think that the interface would change that much anyway.
Regards,
Anthony Liguori
>
> Thiemo
>
>
next prev parent reply other threads:[~2007-09-04 23:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-02 13:50 [Qemu-devel] [PATCH] Patches from PyQemu project Maria Zabolotnaya
2007-09-03 15:41 ` Blue Swirl
2007-09-03 20:44 ` Anthony Liguori
2007-09-04 19:40 ` [Qemu-devel] Re: qemu device emulation libraries (was [PATCH] Patches from the PyQemu project) Hollis Blanchard
2007-09-04 20:04 ` Paul Brook
2007-09-04 20:21 ` Hollis Blanchard
2007-09-04 20:38 ` Paul Brook
2007-09-04 23:38 ` [kvm-devel] " Jimi Xenidis
2007-09-04 20:52 ` Anthony Liguori
2007-09-04 19:57 ` [Qemu-devel] Re: [PATCH] Patches from PyQemu project Brian Johnson
2007-09-04 20:56 ` Anthony Liguori
2007-09-04 22:27 ` Thiemo Seufer
2007-09-04 23:34 ` Anthony Liguori [this message]
2007-09-04 23:45 ` Anthony Liguori
2007-09-05 10:08 ` Fabrice Bellard
2007-09-04 22:13 ` [Qemu-devel] " Paul Sokolovsky
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=1188948857.6627.2.camel@squirrel \
--to=anthony@codemonkey.ws \
--cc=bjj4@charter.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).