From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IShuY-0005A0-6v for qemu-devel@nongnu.org; Tue, 04 Sep 2007 19:34:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IShuX-00058N-F2 for qemu-devel@nongnu.org; Tue, 04 Sep 2007 19:34:21 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IShuX-000581-A1 for qemu-devel@nongnu.org; Tue, 04 Sep 2007 19:34:21 -0400 Received: from wx-out-0506.google.com ([66.249.82.239]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IShuX-0000EI-1I for qemu-devel@nongnu.org; Tue, 04 Sep 2007 19:34:21 -0400 Received: by wx-out-0506.google.com with SMTP id h31so1939610wxd for ; Tue, 04 Sep 2007 16:34:20 -0700 (PDT) Subject: Re: [Qemu-devel] Re: [PATCH] Patches from PyQemu project From: Anthony Liguori In-Reply-To: <20070904222715.GB9977@networkno.de> References: <1aa37d910709020650v7c491985r761886db64435ac0@mail.gmail.com> <1188852253.10151.3.camel@squirrel> <46DDB893.2060403@charter.net> <20070904222715.GB9977@networkno.de> Content-Type: text/plain Date: Tue, 04 Sep 2007 18:34:17 -0500 Message-Id: <1188948857.6627.2.camel@squirrel> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Brian Johnson 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 > >