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 > >
