From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1ISgyK-0007b4-CY
	for qemu-devel@nongnu.org; Tue, 04 Sep 2007 18:34:12 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1ISgyI-0007aT-Cy
	for qemu-devel@nongnu.org; Tue, 04 Sep 2007 18:34:11 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1ISgyI-0007aQ-78
	for qemu-devel@nongnu.org; Tue, 04 Sep 2007 18:34:10 -0400
Received: from phoenix.bawue.net ([193.7.176.60] helo=mail.bawue.net)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <ths@networkno.de>) id 1ISgyH-0004Fs-Rl
	for qemu-devel@nongnu.org; Tue, 04 Sep 2007 18:34:10 -0400
Date: Tue, 4 Sep 2007 23:27:15 +0100
From: Thiemo Seufer <ths@networkno.de>
Subject: Re: [Qemu-devel] Re: [PATCH] Patches from PyQemu project
Message-ID: <20070904222715.GB9977@networkno.de>
References: <1aa37d910709020650v7c491985r761886db64435ac0@mail.gmail.com>
	<f43fc5580709030841n25cad909i58445b6f8645ef97@mail.gmail.com>
	<1188852253.10151.3.camel@squirrel> <46DDB893.2060403@charter.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <46DDB893.2060403@charter.net>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Brian Johnson <bjj4@charter.net>
Cc: qemu-devel@nongnu.org

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.


Thiemo